brine-dsl 0.7.0 → 0.8.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 7f19aef4fbac95c72005238b111b25269e162a6f
-  data.tar.gz: deef83dd9d4164c46912f2ee5af753e12ab4eeba
+  metadata.gz: f8d77b9aa832ed23957643891de0c20ec1890efd
+  data.tar.gz: 229b8e5d0efb6a37a17fa770bb4fe525990c261b
 SHA512:
-  metadata.gz: ef580d0dcba4fc0612f0f01c69bcb88bf077d8f48416a6759a93e964eec369bcab0a531c1bfa007dd4cff8652662f27afeb076872ed15a30c42bbf41acaec43d
-  data.tar.gz: ddd8cbea1ea7b645dab1f5513a5fcc0213ef116b800f1880b1db146c7805ed01ff8398239fa20e1e97bcff13734c1a258153c5c182d103a8bc84070d012d50b9
+  metadata.gz: c0a2015596db450e4fa1abe781bd8eea7d40dcc8d9552a83230f90681c2fc1df1af69af6d01a02778a1de41f7eb220f6d82ae665367f3e8b04a1020be0c18467
+  data.tar.gz: 6d72b507f93ec203e7af1460d23977c4394521cbff2edb4f564a5e3727493b6f9fa7721d6476ec2ff594420e118fa2da47eb7a1f5f0030b1c613c97dcb2e3c1c

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    brine-dsl (0.7.0)
+    brine-dsl (0.8.0)
       cucumber (~> 2.4)
       faraday (~> 0.12)
       faraday_middleware (~> 0.12)

data/LICENSE

@@ -1,6 +1,6 @@
 The MIT License (MIT)
 
-Copyright (c) 2017 Brightcove
+Copyright (c) 2018 Brightcove
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

data/README.adoc

@@ -0,0 +1,29 @@
+= Brine
+
+> Cucumber DSL for testing REST APIs
+
+== Metadata
+
+Documentation::
+  https://brightcove.github.io/brine/
+
+Status::
+  Active
+
+Type::
+  Library
+
+Versioning::
+  Semantic Versioning
+
+Contributing::
+  _To be cleaned up_
+  Contributions are welcome. Guides on developing and contributing
+  are planned, in the short term opening an issue is always a safe
+  choice to avoid any wasted work.
+
+  If you want to contribute or are otherwise interested in the concepts of Brine
+  but may not be fond of the underlying technologies...also feel free to open a
+  ticket. All of the current choices were driven by practicality rather than
+  preference or being considered the best long term solution for the problem, so
+  there's still a strong chance for collaboration and convergence.

data/brine-dsl.gemspec

@@ -1,7 +1,7 @@
 # -*- encoding: utf-8 -*-
 Gem::Specification.new do |s|
   s.name         = 'brine-dsl'
-  s.version      = '0.7.0'
+  s.version      = '0.8.0'
   s.platform     = Gem::Platform::RUBY
   s.authors      = ["Matt Whipple"]
   s.email        = ["mwhipple@brightcove.com"]
@@ -20,11 +20,11 @@ Gem::Specification.new do |s|
   s.add_runtime_dependency     'faraday',            '~> 0.12'
   s.add_runtime_dependency     'faraday_middleware', '~> 0.12'
 
-  s.add_development_dependency 'rake',		     '~> 12.3'
-  s.add_development_dependency 'aruba',		     '~> 0.14'
-  s.add_development_dependency 'guard',		     '~> 2.14'
+  s.add_development_dependency 'rake',               '~> 12.3'
+  s.add_development_dependency 'aruba',              '~> 0.14'
+  s.add_development_dependency 'guard',              '~> 2.14'
   s.add_development_dependency 'guard-cucumber',     '~> 2.1'
-  s.add_development_dependency 'asciidoctor',	     '~> 1.5'
+  s.add_development_dependency 'asciidoctor',        '~> 1.5'
 
   s.files        = `git ls-files`.split("\n")
   s.test_files   = `git ls-files -- {test,spec,features}/*`.split("\n")

data/docs/build.gradle

@@ -1,5 +1,5 @@
 plugins {
-    id "org.asciidoctor.gradle.asciidoctor" version "1.5.1"
+    id 'org.asciidoctor.gradle.asciidoctor' version '1.5.1'
 }
 
 dependencies {

data/docs/cookbook.html

@@ -450,13 +450,13 @@ body.book #toc,body.book #preamble,body.book h1.sect0,body.book .sect1>h2{page-b
 <div class="sectionbody">
 <div class="paragraph">
 <p>The following are some recipes to address issues which may arise while using
-Brine but are not considered part of Brine&#8217;s responsibility (at least presently).
-Many of these are focused on simplicity and ease rather than robustness or elegance,
-and modification to address specific cases should be expected.</p>
+Brine but are not considered part of Brine&#8217;s (current) responsibility.
+Many of these are focused on simplicity and ease rather than robustness or
+elegance, and modification to address specific cases should be expected.</p>
 </div>
 <div class="paragraph">
-<p>Many of these will also be platform specific and be subject to further organization
-once platforms beyond ruby are supported.</p>
+<p>Many of these will also be platform specific and be subject to further
+organization once platforms beyond ruby are supported.</p>
 </div>
 </div>
 </div>
@@ -479,10 +479,12 @@ of anything that belongs in the specification.</p>
 the Brine client. All of the registered middleware attaches
 to the generated connection through an array of functions in
 <a href="https://github.com/brightcove/brine/blob/master/lib/brine/requester.rb">requester.rb</a>.
-Each function accepts the connection object as its single parameter. The array of functions
-is exposed as <code>connection_handlers</code>  and can be modified through getting that property
-from either the default <code>World</code> (for the default client) or from an appropriate <code>ClientBuilder</code>
-if creating custom clients and mutating it accordingly (setting the reference is not suported).
+Each function accepts the connection object as its single parameter.
+The array of functions is exposed as <code>connection_handlers</code> and can be modified
+through getting that property from either the default <code>World</code>
+(for the default client) or from an appropriate <code>ClientBuilder</code>
+if creating custom clients and mutating it accordingly (setting the reference
+is not suported).
 You could just build your own client without the facilities provided by Brine.</p>
 </div>
 </div>
@@ -537,47 +539,52 @@ additional overhead to provision a new account. When testing a secured
 system valid accounts are needed for representative testing, but provisioning
 a new account may be difficult or outside the scope of the system that is being
 actively tested. If tested functionality involves enacting account-wide changes
-and the number of accounts is limited, then that is likely to unfortunately prevent
-complete test isolation.</p>
+and the number of accounts is limited, then that is likely to unfortunately
+prevent complete test isolation.</p>
 </div>
 </div>
 <div class="sect2">
 <h3 id="_solution_2">Solution</h3>
 <div class="paragraph">
-<p>In such cases a standard solution is to designate certain resources to be reused for
-certain tests. These are analogous to the concept of "fixtures" in some test suites
-though there may be slight differences in implementation and reliance on them.
-Here the term "assurances" is used..primarily because it starts with <code>a</code> which lends
-itself to relevant files being listed towards the beginning alphabetically in a given directory.</p>
+<p>In such cases a standard solution is to designate certain resources to be
+reused for certain tests. These are analogous to the concept of "fixtures" in
+some test suites though there may be slight differences in implementation and
+reliance on them. Here the term "assurances" is used&#8230;&#8203;primarily because it
+starts with <code>a</code> which lends itself to relevant files being listed towards the
+beginning alphabetically in a given directory.</p>
 </div>
 <div class="paragraph">
 <p>The goal of assurances is to specify conditions which are expected before other
-tests are to be run. Preferably the dependent tests should also explicitly declare the
-dependency but a significant solution for that is not established. Assurances therefore
-validate that preconditions are met; ideally if such preconditions can be established
-idempotently then the assurances can do so before the validation.</p>
+tests are to be run. Preferably the dependent tests should also explicitly
+declare the dependency but a significant solution for that is not established.
+Assurances therefore validate that preconditions are met; ideally if such
+preconditions can be established idempotently then the assurances can do so
+before the validation.</p>
 </div>
 <div class="sect3">
 <h4 id="_assurances_are_not_tests">Assurances are NOT Tests</h4>
 <div class="paragraph">
-<p><strong>Assurances validate a state which is desired to be consistently retained within the
-system rather than being changed</strong>. This means that they should <em>not</em> be used for tests
-as that would require state changes, nor should they clean up after themselves (as that
-would also imply a state change). If assurances are configured for a system which should
-also be tested, then appropriate tests should exist (including those that may validate any
-behavior relied upon by the assurance).</p>
+<p><strong>Assurances validate a state which is desired to be consistently retained
+within the system rather than being changed</strong>. This means that they should <em>not</em>
+be used for tests as that would require state changes, nor should they clean up
+after themselves (as that would also imply a state change). If assurances are
+configured for a system which should also be tested, then appropriate tests
+should exist (including those that may validate any behavior relied upon by
+the assurance).</p>
 </div>
 </div>
 <div class="sect3">
 <h4 id="_consequences">Consequences</h4>
 <div class="paragraph">
-<p>As mentioned previously assertions help in cases where tests cannot be fully isolated,
-and therefore some known state must be established and reused across tests (and such state
-should <strong>not</strong> change). A practical reason for this is to allow for overlapping test executions.
-If tests are not fully isolated, state is being changed, and test runs overlap, then tests
-may fail non-deterministically due to one test run pulling the state out from another. This
-in the simplest form can be a nuisance but it also effectively precludes the ability to speed
-up test runs through the use of parallelism/asynchronicity.</p>
+<p>As mentioned previously assertions help in cases where tests cannot be fully
+isolated, and therefore some known state must be established and reused across
+tests (and such state should <strong>not</strong> change). A practical reason for this is to
+allow for overlapping test executions.
+If tests are not fully isolated, state is being changed, and test runs overlap,
+then tests may fail non-deterministically due to one test run pulling the state
+out from another. This in the simplest form can be a nuisance but it also
+effectively precludes the ability to speed up test runs through the use of
+parallelism/asynchronicity.</p>
 </div>
 <div class="paragraph">
 <p><em>TODO: Enumerate drawbacks</em></p>
@@ -587,8 +594,8 @@ up test runs through the use of parallelism/asynchronicity.</p>
 <div class="sect2">
 <h3 id="_recipe_2">Recipe</h3>
 <div class="paragraph">
-<p>This can be done using standard cucumber tags. Assurances can be defined in designated
-<code>assure_*.feature</code> files where each Feature is appropriately tagged:</p>
+<p>This can be done using standard cucumber tags. Assurances can be defined in
+designated <code>assure_*.feature</code> files where each Feature is appropriately tagged:</p>
 </div>
 <div class="listingblock">
 <div class="content">
@@ -617,10 +624,11 @@ end</code></pre>
 </div>
 </div>
 <div class="paragraph">
-<p>This approach tests preconditions and will avoid running the rest of the tests if they
-are not (relying on standard Rake behavior). The assurances can also be run with different
-Cucumber behavior so that the full test suite can be more stochastic
-(randomized/non-serialized) while the assurances can be more controlled.</p>
+<p>This approach tests preconditions and will avoid running the rest of the tests
+if they are not (relying on standard Rake behavior). The assurances can also be
+run with different Cucumber behavior so that the full test suite can be more
+stochastic (randomized/non-serialized) while the assurances can be more
+controlled.</p>
 </div>
 </div>
 </div>
@@ -628,7 +636,7 @@ Cucumber behavior so that the full test suite can be more stochastic
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 2018-05-30 12:01:52 EDT
+Last updated 2018-06-17 15:55:45 EDT
 </div>
 </div>
 </body>