brine-dsl 0.7.0 → 0.8.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA1:
3
- metadata.gz: 7f19aef4fbac95c72005238b111b25269e162a6f
4
- data.tar.gz: deef83dd9d4164c46912f2ee5af753e12ab4eeba
3
+ metadata.gz: f8d77b9aa832ed23957643891de0c20ec1890efd
4
+ data.tar.gz: 229b8e5d0efb6a37a17fa770bb4fe525990c261b
5
5
  SHA512:
6
- metadata.gz: ef580d0dcba4fc0612f0f01c69bcb88bf077d8f48416a6759a93e964eec369bcab0a531c1bfa007dd4cff8652662f27afeb076872ed15a30c42bbf41acaec43d
7
- data.tar.gz: ddd8cbea1ea7b645dab1f5513a5fcc0213ef116b800f1880b1db146c7805ed01ff8398239fa20e1e97bcff13734c1a258153c5c182d103a8bc84070d012d50b9
6
+ metadata.gz: c0a2015596db450e4fa1abe781bd8eea7d40dcc8d9552a83230f90681c2fc1df1af69af6d01a02778a1de41f7eb220f6d82ae665367f3e8b04a1020be0c18467
7
+ data.tar.gz: 6d72b507f93ec203e7af1460d23977c4394521cbff2edb4f564a5e3727493b6f9fa7721d6476ec2ff594420e118fa2da47eb7a1f5f0030b1c613c97dcb2e3c1c
data/Gemfile.lock CHANGED
@@ -1,7 +1,7 @@
1
1
  PATH
2
2
  remote: .
3
3
  specs:
4
- brine-dsl (0.7.0)
4
+ brine-dsl (0.8.0)
5
5
  cucumber (~> 2.4)
6
6
  faraday (~> 0.12)
7
7
  faraday_middleware (~> 0.12)
data/LICENSE CHANGED
@@ -1,6 +1,6 @@
1
1
  The MIT License (MIT)
2
2
 
3
- Copyright (c) 2017 Brightcove
3
+ Copyright (c) 2018 Brightcove
4
4
 
5
5
  Permission is hereby granted, free of charge, to any person obtaining a copy
6
6
  of this software and associated documentation files (the "Software"), to deal
data/README.adoc ADDED
@@ -0,0 +1,29 @@
1
+ = Brine
2
+
3
+ > Cucumber DSL for testing REST APIs
4
+
5
+ == Metadata
6
+
7
+ Documentation::
8
+ https://brightcove.github.io/brine/
9
+
10
+ Status::
11
+ Active
12
+
13
+ Type::
14
+ Library
15
+
16
+ Versioning::
17
+ Semantic Versioning
18
+
19
+ Contributing::
20
+ _To be cleaned up_
21
+ Contributions are welcome. Guides on developing and contributing
22
+ are planned, in the short term opening an issue is always a safe
23
+ choice to avoid any wasted work.
24
+
25
+ If you want to contribute or are otherwise interested in the concepts of Brine
26
+ but may not be fond of the underlying technologies...also feel free to open a
27
+ ticket. All of the current choices were driven by practicality rather than
28
+ preference or being considered the best long term solution for the problem, so
29
+ there's still a strong chance for collaboration and convergence.
data/brine-dsl.gemspec CHANGED
@@ -1,7 +1,7 @@
1
1
  # -*- encoding: utf-8 -*-
2
2
  Gem::Specification.new do |s|
3
3
  s.name = 'brine-dsl'
4
- s.version = '0.7.0'
4
+ s.version = '0.8.0'
5
5
  s.platform = Gem::Platform::RUBY
6
6
  s.authors = ["Matt Whipple"]
7
7
  s.email = ["mwhipple@brightcove.com"]
@@ -20,11 +20,11 @@ Gem::Specification.new do |s|
20
20
  s.add_runtime_dependency 'faraday', '~> 0.12'
21
21
  s.add_runtime_dependency 'faraday_middleware', '~> 0.12'
22
22
 
23
- s.add_development_dependency 'rake', '~> 12.3'
24
- s.add_development_dependency 'aruba', '~> 0.14'
25
- s.add_development_dependency 'guard', '~> 2.14'
23
+ s.add_development_dependency 'rake', '~> 12.3'
24
+ s.add_development_dependency 'aruba', '~> 0.14'
25
+ s.add_development_dependency 'guard', '~> 2.14'
26
26
  s.add_development_dependency 'guard-cucumber', '~> 2.1'
27
- s.add_development_dependency 'asciidoctor', '~> 1.5'
27
+ s.add_development_dependency 'asciidoctor', '~> 1.5'
28
28
 
29
29
  s.files = `git ls-files`.split("\n")
30
30
  s.test_files = `git ls-files -- {test,spec,features}/*`.split("\n")
data/docs/build.gradle CHANGED
@@ -1,5 +1,5 @@
1
1
  plugins {
2
- id "org.asciidoctor.gradle.asciidoctor" version "1.5.1"
2
+ id 'org.asciidoctor.gradle.asciidoctor' version '1.5.1'
3
3
  }
4
4
 
5
5
  dependencies {
data/docs/cookbook.html CHANGED
@@ -450,13 +450,13 @@ body.book #toc,body.book #preamble,body.book h1.sect0,body.book .sect1>h2{page-b
450
450
  <div class="sectionbody">
451
451
  <div class="paragraph">
452
452
  <p>The following are some recipes to address issues which may arise while using
453
- Brine but are not considered part of Brine&#8217;s responsibility (at least presently).
454
- Many of these are focused on simplicity and ease rather than robustness or elegance,
455
- and modification to address specific cases should be expected.</p>
453
+ Brine but are not considered part of Brine&#8217;s (current) responsibility.
454
+ Many of these are focused on simplicity and ease rather than robustness or
455
+ elegance, and modification to address specific cases should be expected.</p>
456
456
  </div>
457
457
  <div class="paragraph">
458
- <p>Many of these will also be platform specific and be subject to further organization
459
- once platforms beyond ruby are supported.</p>
458
+ <p>Many of these will also be platform specific and be subject to further
459
+ organization once platforms beyond ruby are supported.</p>
460
460
  </div>
461
461
  </div>
462
462
  </div>
@@ -479,10 +479,12 @@ of anything that belongs in the specification.</p>
479
479
  the Brine client. All of the registered middleware attaches
480
480
  to the generated connection through an array of functions in
481
481
  <a href="https://github.com/brightcove/brine/blob/master/lib/brine/requester.rb">requester.rb</a>.
482
- Each function accepts the connection object as its single parameter. The array of functions
483
- is exposed as <code>connection_handlers</code> and can be modified through getting that property
484
- from either the default <code>World</code> (for the default client) or from an appropriate <code>ClientBuilder</code>
485
- if creating custom clients and mutating it accordingly (setting the reference is not suported).
482
+ Each function accepts the connection object as its single parameter.
483
+ The array of functions is exposed as <code>connection_handlers</code> and can be modified
484
+ through getting that property from either the default <code>World</code>
485
+ (for the default client) or from an appropriate <code>ClientBuilder</code>
486
+ if creating custom clients and mutating it accordingly (setting the reference
487
+ is not suported).
486
488
  You could just build your own client without the facilities provided by Brine.</p>
487
489
  </div>
488
490
  </div>
@@ -537,47 +539,52 @@ additional overhead to provision a new account. When testing a secured
537
539
  system valid accounts are needed for representative testing, but provisioning
538
540
  a new account may be difficult or outside the scope of the system that is being
539
541
  actively tested. If tested functionality involves enacting account-wide changes
540
- and the number of accounts is limited, then that is likely to unfortunately prevent
541
- complete test isolation.</p>
542
+ and the number of accounts is limited, then that is likely to unfortunately
543
+ prevent complete test isolation.</p>
542
544
  </div>
543
545
  </div>
544
546
  <div class="sect2">
545
547
  <h3 id="_solution_2">Solution</h3>
546
548
  <div class="paragraph">
547
- <p>In such cases a standard solution is to designate certain resources to be reused for
548
- certain tests. These are analogous to the concept of "fixtures" in some test suites
549
- though there may be slight differences in implementation and reliance on them.
550
- Here the term "assurances" is used..primarily because it starts with <code>a</code> which lends
551
- itself to relevant files being listed towards the beginning alphabetically in a given directory.</p>
549
+ <p>In such cases a standard solution is to designate certain resources to be
550
+ reused for certain tests. These are analogous to the concept of "fixtures" in
551
+ some test suites though there may be slight differences in implementation and
552
+ reliance on them. Here the term "assurances" is used&#8230;&#8203;primarily because it
553
+ starts with <code>a</code> which lends itself to relevant files being listed towards the
554
+ beginning alphabetically in a given directory.</p>
552
555
  </div>
553
556
  <div class="paragraph">
554
557
  <p>The goal of assurances is to specify conditions which are expected before other
555
- tests are to be run. Preferably the dependent tests should also explicitly declare the
556
- dependency but a significant solution for that is not established. Assurances therefore
557
- validate that preconditions are met; ideally if such preconditions can be established
558
- idempotently then the assurances can do so before the validation.</p>
558
+ tests are to be run. Preferably the dependent tests should also explicitly
559
+ declare the dependency but a significant solution for that is not established.
560
+ Assurances therefore validate that preconditions are met; ideally if such
561
+ preconditions can be established idempotently then the assurances can do so
562
+ before the validation.</p>
559
563
  </div>
560
564
  <div class="sect3">
561
565
  <h4 id="_assurances_are_not_tests">Assurances are NOT Tests</h4>
562
566
  <div class="paragraph">
563
- <p><strong>Assurances validate a state which is desired to be consistently retained within the
564
- system rather than being changed</strong>. This means that they should <em>not</em> be used for tests
565
- as that would require state changes, nor should they clean up after themselves (as that
566
- would also imply a state change). If assurances are configured for a system which should
567
- also be tested, then appropriate tests should exist (including those that may validate any
568
- behavior relied upon by the assurance).</p>
567
+ <p><strong>Assurances validate a state which is desired to be consistently retained
568
+ within the system rather than being changed</strong>. This means that they should <em>not</em>
569
+ be used for tests as that would require state changes, nor should they clean up
570
+ after themselves (as that would also imply a state change). If assurances are
571
+ configured for a system which should also be tested, then appropriate tests
572
+ should exist (including those that may validate any behavior relied upon by
573
+ the assurance).</p>
569
574
  </div>
570
575
  </div>
571
576
  <div class="sect3">
572
577
  <h4 id="_consequences">Consequences</h4>
573
578
  <div class="paragraph">
574
- <p>As mentioned previously assertions help in cases where tests cannot be fully isolated,
575
- and therefore some known state must be established and reused across tests (and such state
576
- should <strong>not</strong> change). A practical reason for this is to allow for overlapping test executions.
577
- If tests are not fully isolated, state is being changed, and test runs overlap, then tests
578
- may fail non-deterministically due to one test run pulling the state out from another. This
579
- in the simplest form can be a nuisance but it also effectively precludes the ability to speed
580
- up test runs through the use of parallelism/asynchronicity.</p>
579
+ <p>As mentioned previously assertions help in cases where tests cannot be fully
580
+ isolated, and therefore some known state must be established and reused across
581
+ tests (and such state should <strong>not</strong> change). A practical reason for this is to
582
+ allow for overlapping test executions.
583
+ If tests are not fully isolated, state is being changed, and test runs overlap,
584
+ then tests may fail non-deterministically due to one test run pulling the state
585
+ out from another. This in the simplest form can be a nuisance but it also
586
+ effectively precludes the ability to speed up test runs through the use of
587
+ parallelism/asynchronicity.</p>
581
588
  </div>
582
589
  <div class="paragraph">
583
590
  <p><em>TODO: Enumerate drawbacks</em></p>
@@ -587,8 +594,8 @@ up test runs through the use of parallelism/asynchronicity.</p>
587
594
  <div class="sect2">
588
595
  <h3 id="_recipe_2">Recipe</h3>
589
596
  <div class="paragraph">
590
- <p>This can be done using standard cucumber tags. Assurances can be defined in designated
591
- <code>assure_*.feature</code> files where each Feature is appropriately tagged:</p>
597
+ <p>This can be done using standard cucumber tags. Assurances can be defined in
598
+ designated <code>assure_*.feature</code> files where each Feature is appropriately tagged:</p>
592
599
  </div>
593
600
  <div class="listingblock">
594
601
  <div class="content">
@@ -617,10 +624,11 @@ end</code></pre>
617
624
  </div>
618
625
  </div>
619
626
  <div class="paragraph">
620
- <p>This approach tests preconditions and will avoid running the rest of the tests if they
621
- are not (relying on standard Rake behavior). The assurances can also be run with different
622
- Cucumber behavior so that the full test suite can be more stochastic
623
- (randomized/non-serialized) while the assurances can be more controlled.</p>
627
+ <p>This approach tests preconditions and will avoid running the rest of the tests
628
+ if they are not (relying on standard Rake behavior). The assurances can also be
629
+ run with different Cucumber behavior so that the full test suite can be more
630
+ stochastic (randomized/non-serialized) while the assurances can be more
631
+ controlled.</p>
624
632
  </div>
625
633
  </div>
626
634
  </div>
@@ -628,7 +636,7 @@ Cucumber behavior so that the full test suite can be more stochastic
628
636
  </div>
629
637
  <div id="footer">
630
638
  <div id="footer-text">
631
- Last updated 2018-05-30 12:01:52 EDT
639
+ Last updated 2018-06-17 15:55:45 EDT
632
640
  </div>
633
641
  </div>
634
642
  </body>