brine-dsl 0.7.0 → 0.8.0
Sign up to get free protection for your applications and to get access to all the features.
- 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>
|