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 +4 -4
- data/Gemfile.lock +1 -1
- data/LICENSE +1 -1
- data/README.adoc +29 -0
- data/brine-dsl.gemspec +5 -5
- data/docs/build.gradle +1 -1
- data/docs/cookbook.html +48 -40
- data/docs/guide.html +185 -119
- data/docs/index.html +18 -4
- data/docs/specs.html +227 -1
- data/docs/src/cookbook.adoc +57 -40
- data/docs/src/guide.adoc +227 -133
- data/docs/src/index.adoc +15 -3
- data/docs/src/specs.adoc +11 -0
- data/features/assignment/parameter.feature +20 -0
- data/features/assignment/random.feature +25 -0
- data/features/assignment/response_attribute.feature +33 -0
- data/features/assignment/timestamp.feature +33 -0
- data/lib/brine/cleaner_upper.rb +55 -16
- data/lib/brine/coercer.rb +55 -5
- data/lib/brine/rest_steps.rb +20 -39
- data/lib/brine/step_definitions/assignment.rb +33 -5
- data/lib/brine.rb +13 -8
- metadata +11 -3
- data/README.md +0 -7
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA1:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: f8d77b9aa832ed23957643891de0c20ec1890efd
|
4
|
+
data.tar.gz: 229b8e5d0efb6a37a17fa770bb4fe525990c261b
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: c0a2015596db450e4fa1abe781bd8eea7d40dcc8d9552a83230f90681c2fc1df1af69af6d01a02778a1de41f7eb220f6d82ae665367f3e8b04a1020be0c18467
|
7
|
+
data.tar.gz: 6d72b507f93ec203e7af1460d23977c4394521cbff2edb4f564a5e3727493b6f9fa7721d6476ec2ff594420e118fa2da47eb7a1f5f0030b1c613c97dcb2e3c1c
|
data/Gemfile.lock
CHANGED
data/LICENSE
CHANGED
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.
|
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',
|
24
|
-
s.add_development_dependency 'aruba',
|
25
|
-
s.add_development_dependency 'guard',
|
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',
|
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
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’s
|
454
|
-
Many of these are focused on simplicity and ease rather than robustness or
|
455
|
-
and modification to address specific cases should be expected.</p>
|
453
|
+
Brine but are not considered part of Brine’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
|
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.
|
483
|
-
is exposed as <code>connection_handlers</code>
|
484
|
-
|
485
|
-
|
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
|
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
|
548
|
-
certain tests. These are analogous to the concept of "fixtures" in
|
549
|
-
though there may be slight differences in implementation and
|
550
|
-
Here the term "assurances" is used
|
551
|
-
itself to relevant files being listed towards the
|
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…​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
|
556
|
-
dependency but a significant solution for that is not established.
|
557
|
-
validate that preconditions are met; ideally if such
|
558
|
-
idempotently then the assurances can do so
|
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
|
564
|
-
system rather than being changed</strong>. This means that they should <em>not</em>
|
565
|
-
as that would require state changes, nor should they clean up
|
566
|
-
would also imply a state change). If assurances are
|
567
|
-
also be tested, then appropriate tests
|
568
|
-
behavior relied upon by
|
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
|
575
|
-
and therefore some known state must be established and reused across
|
576
|
-
should <strong>not</strong> change). A practical reason for this is to
|
577
|
-
|
578
|
-
|
579
|
-
|
580
|
-
|
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
|
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
|
621
|
-
are not (relying on standard Rake behavior). The assurances can also be
|
622
|
-
Cucumber behavior so that the full test suite can be more
|
623
|
-
(randomized/non-serialized) while the assurances can be more
|
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-
|
639
|
+
Last updated 2018-06-17 15:55:45 EDT
|
632
640
|
</div>
|
633
641
|
</div>
|
634
642
|
</body>
|