rspec-given 2.4.4 → 2.4.5

Sign up to get free protection for your applications and to get access to all the features.
data/README.old DELETED
@@ -1,679 +0,0 @@
1
- # rspec-given
2
-
3
- | Master |
4
- | :----: |
5
- | [![Master Build Status](https://secure.travis-ci.org/jimweirich/rspec-given.png?branch=master)](https://travis-ci.org/jimweirich/rspec-given) |
6
-
7
- Covering rspec-given, version 2.4.3.
8
-
9
- rspec-given is an RSpec extension to allow Given/When/Then notation in
10
- RSpec specifications. It is a natural extension of the experimental
11
- work done on the Given framework.
12
-
13
- # Why Given/When/Then
14
-
15
- RSpec has done a great job of making specifications more readable for
16
- humans. However, I really like the given / when / then nature of
17
- Cucumber stories and would like to follow the same structure in my
18
- unit tests. rspec-given allows a simple given/when/then structure
19
- RSpec specifications.
20
-
21
- ## Status
22
-
23
- rspec-given is ready for production use.
24
-
25
- ## Example
26
-
27
- Here is a specification written in the rspec-given framework:
28
-
29
- ```ruby
30
- require 'rspec/given'
31
- require 'spec_helper'
32
- require 'stack'
33
-
34
- describe Stack do
35
- def stack_with(initial_contents)
36
- stack = Stack.new
37
- initial_contents.each do |item| stack.push(item) end
38
- stack
39
- end
40
-
41
- Given(:stack) { stack_with(initial_contents) }
42
- Invariant { stack.empty?.should == (stack.depth == 0) }
43
-
44
- context "with no items" do
45
- Given(:initial_contents) { [] }
46
- Then { stack.depth.should == 0 }
47
-
48
- context "when pushing" do
49
- When { stack.push(:an_item) }
50
-
51
- Then { stack.depth.should == 1 }
52
- Then { stack.top.should == :an_item }
53
- end
54
-
55
- context "when popping" do
56
- When(:result) { stack.pop }
57
- Then { result.should have_failed(Stack::UnderflowError, /empty/) }
58
- end
59
- end
60
-
61
- context "with one item" do
62
- Given(:initial_contents) { [:an_item] }
63
-
64
- context "when popping" do
65
- When(:pop_result) { stack.pop }
66
-
67
- Then { pop_result.should == :an_item }
68
- Then { stack.depth.should == 0 }
69
- end
70
- end
71
-
72
- context "with several items" do
73
- Given(:initial_contents) { [:second_item, :top_item] }
74
- Given!(:original_depth) { stack.depth }
75
-
76
- context "when pushing" do
77
- When { stack.push(:new_item) }
78
-
79
- Then { stack.top.should == :new_item }
80
- Then { stack.depth.should == original_depth + 1 }
81
- end
82
-
83
- context "when popping" do
84
- When(:pop_result) { stack.pop }
85
-
86
- Then { pop_result.should == :top_item }
87
- Then { stack.top.should == :second_item }
88
- Then { stack.depth.should == original_depth - 1 }
89
- end
90
- end
91
- end
92
- ```
93
-
94
- Let's talk about the individual statements used in the Given
95
- framework.
96
-
97
- ### Given
98
-
99
- The _Given_ section specifies a starting point, a set of preconditions
100
- that must be true before the code under test is allowed to be run. In
101
- standard test frameworks the preconditions are established with a
102
- combination of setup methods (or :before actions in RSpec) and code in
103
- the test.
104
-
105
- In the example code above the preconditions are started with _Given_
106
- statements. A top level _Given_ (that applies to the entire describe
107
- block) says that one of the preconditions is that there is a stack
108
- with some initial contents.
109
-
110
- Note that initial contents are not specified in the top level describe
111
- block, but are given in each of the nested contexts. By pushing the
112
- definition of "initial_contents" into the nested contexts, we can vary
113
- them as needed for that particular context.
114
-
115
- A precondition in the form "Given(:var) {...}" creates an accessor
116
- method named "var". The accessor is lazily initialized by the code
117
- block. If you want a non-lazy given, use "Given!(:var) {...}".
118
-
119
- A precondition in the form "Given {...}" just executes the code block
120
- for side effects. Since there is no accessor, the code block is
121
- executed immediately (i.e. no lazy evaluation).
122
-
123
- The preconditions are run in order of definition. Nested contexts
124
- will inherit the preconditions from the enclosing context, with outer
125
- preconditions running before inner preconditions.
126
-
127
- #### Given examples:
128
-
129
- ```ruby
130
- Given(:stack) { Stack.new }
131
- ```
132
-
133
- The block for the given clause is lazily run and its value bound to
134
- 'stack' if 'stack' is ever referenced in the test.
135
- The first reference to 'stack' in the specification will cause the
136
- code block to execute. Futher references to 'stack' will reuse the
137
- previously generated value.
138
-
139
- ```ruby
140
- Given!(:original_size) { stack.size }
141
- ```
142
-
143
- The code block is run unconditionally once before each test and the
144
- value of the block is bound to 'original_size'. This form is useful
145
- when you want to record the value of something that might be affected
146
- by the When code.
147
-
148
- ```ruby
149
- Given { stack.clear }
150
- ```
151
-
152
- The block for the given clause is run unconditionally once before each
153
- test. This form of given is used for code that is executed for side
154
- effects.
155
-
156
- ### When
157
-
158
- The _When_ clause specifies the code to be tested ... oops, excuse me
159
- ... specified. After the preconditions in the given section are met,
160
- the when code block is run.
161
-
162
- In general there should not be more than one _When_ clause for a given
163
- direct context. However, a _When_ in an outer context will be run
164
- after all the _Givens_ but before the inner _When_. You can think of
165
- an outer _When_ as setting up additional given state for the inner
166
- _When_.
167
-
168
- E.g.
169
-
170
- ```ruby
171
- context "outer context" do
172
- When { code specified in the outer context }
173
- Then { assert something about the outer context }
174
-
175
- context "inner context" do
176
-
177
- # At this point, the _When_ of the outer context
178
- # should be treated as a _Given_ of the inner context
179
-
180
- When { code specified in the inner context }
181
- Then { assert something about the inner context }
182
- end
183
- end
184
- ```
185
-
186
- #### When examples:
187
-
188
- ```ruby
189
- When { stack.push(:item) }
190
- ```
191
-
192
- The code block is executed once per test. The effect of the _When{}_
193
- block is very similar to _Given{}_. However, When is used to identify
194
- the particular code that is being specified in the current context or
195
- describe block.
196
-
197
- ```ruby
198
- When(:result) { stack.pop }
199
- ```
200
-
201
- The code block is executed once per test and the value of the code
202
- block is bound to 'result'. Use this form when the code under test
203
- returns a value that you wish to interrogate in the _Then_ code.
204
-
205
- If an exception occurs during the execution of the block for the When
206
- clause, the exception is caught and a failure object is bound to
207
- 'result'. The failure can be checked in a then block with the
208
- 'have_failed' matcher.
209
-
210
- The failure object will rethrow the captured exception if anything
211
- other than have_failed matcher is used on the failure object.
212
-
213
- For example, if the stack is empty when it is popped, then it is
214
- reasonable for pop to raise an UnderflowError. This is how you might
215
- specify that behavior:
216
-
217
- ```ruby
218
- When(:result) { stack.pop }
219
- Then { result.should have_failed(UnderflowError, /empty/) }
220
- ```
221
-
222
- Note that the arguments to the 'have_failed' matcher are the same as
223
- those given to the standard RSpec matcher 'raise_error'.
224
-
225
- ### Then
226
-
227
- The _Then_ clauses are the postconditions of the specification. These
228
- then conditions must be true after the code under test (the _When_
229
- clause) is run.
230
-
231
- The code in the block of a _Then_ clause should be a single _should_
232
- assertion. Code in _Then_ clauses should not have any side effects.
233
-
234
- Let me repeat that: <b>_Then_ clauses should not have any side
235
- effects!</b> _Then_ clauses with side effects are erroneous. _Then_
236
- clauses need to be idempotent, so that running them once, twice, a
237
- hundred times, or never does not change the state of the program. (The
238
- same is true of _And_ and _Invariant_ clauses).
239
-
240
- In RSpec terms, a _Then_ clause forms a RSpec Example that runs in the
241
- context of an Example Group (defined by a describe or context clause).
242
-
243
- Each Example Group must have at least one _Then_ clause, otherwise
244
- there will be no examples to be run for that group. If all the
245
- assertions in an example group are done via Invariants, then the group
246
- should use an empty _Then_ clause, like this:
247
-
248
- ```ruby
249
- Then { }
250
- ```
251
-
252
- #### Then examples:
253
-
254
- ```ruby
255
- Then { stack.should be_empty }
256
- ```
257
-
258
- After the related block for the _When_ clause is run, the stack should
259
- be empty. If it is not empty, the test will fail.
260
-
261
- ### And
262
-
263
- The _And_ clause is similar to _Then_, but does not form its own RSpec
264
- example. This means that _And_ clauses reuse the setup from a sibling
265
- _Then_ clause. Using a single _Then_ and multiple _And_ clauses in an
266
- example group means the setup for that group is run only once (for the
267
- _Then_ clause) and reused for all the _And_ clauses. This can be a
268
- significant speed savings where the setup for an example group is
269
- expensive.
270
-
271
- Some things to keep in mind about _And_ clauses:
272
-
273
- * There must be at least one _Then_ in the example group and it must
274
- be declared before the _And_ clauses. Forgetting the _Then_ clause
275
- is an error.
276
-
277
- * The code in the _And_ clause is run immediately after the first
278
- (executed) _Then_ of an example group.
279
-
280
- * An assertion failure in a _Then_ clause or an _And_ clause will
281
- cause all the subsequent _And_ clauses to be skipped.
282
-
283
- * Since _And_ clauses do not form their own RSpec examples, they are
284
- not represented in the formatted output of RSpec. That means _And_
285
- clauses do not produce dots in the Progress format, nor do they
286
- appear in the documentation, html or textmate formats (options
287
- -fhtml, -fdoc, or -ftextmate).
288
-
289
- * Like _Then_ clauses, _And_ clauses must be idempotent. That means
290
- they should not execute any code that changes global program state.
291
- (See the section on the _Then_ clause).
292
-
293
- The choice to use an _And_ clause is primarily a speed consideration.
294
- If an example group has expensive setup and there are a lot of _Then_
295
- clauses, then choosing to make some of the _Then_ clauses into _And_
296
- clauses will speed up the spec. Otherwise it is probably better to
297
- stick with _Then_ clauses.
298
-
299
- #### Then/And examples:
300
-
301
- ```ruby
302
- Then { pop_result.should == :top_item } # Required
303
- And { stack.top.should == :second_item } # No Setup rerun
304
- And { stack.depth.should == original_depth - 1 } # ... for these
305
- ```
306
-
307
- ### Invariant
308
-
309
- The _Invariant_ clause is a new idea that doesn't have an analog in
310
- RSpec or Test::Unit. The invariant allows you specify things that must
311
- always be true in the scope of the invariant. In the stack example, the method
312
- <tt>empty?</tt> is defined in term of <tt>size</tt>.
313
-
314
- ```ruby
315
- Invariant { stack.empty? == (stack.depth == 0) }
316
- ```
317
-
318
- This invariant states that <code>empty?</code> is true if and only if
319
- the stack depth is zero, and that assertion is checked at every _Then_
320
- clause that is in the same scope.
321
-
322
- You can conceptually think of an _Invariant_ clause as a _Then_ block
323
- that automatically gets added to every _Then_ within its scope.
324
- Invariants nested within a context only apply to the _Then_ clauses
325
- that are in the scope of that context.
326
-
327
- Invariants that reference a _Given_ precondition accessor must only be
328
- used in contexts that define that accessor.
329
-
330
- Notes:
331
-
332
- * Since Invariants do not form their own RSpec example, they are not
333
- represented in the RSpec formatted output (e.g. the '--format html'
334
- option).
335
-
336
- ## Execution Ordering
337
-
338
- When running the test for a specific _Then_ clause, the following will
339
- be true:
340
-
341
- * The non-lazy _Given_ clauses will be run in the order that they are
342
- specified, from the outermost scope to the innermost scope
343
- containing the _Then_. (The lazy _Given_ clauses will be run upon
344
- demand).
345
-
346
- * All of the _Given_ clauses in all of the relevant scopes will run
347
- before the first (outermost) _When_ clause in those same scopes.
348
- That means that the _When_ code can assume that the givens have been
349
- established, even if the givens are in a more nested scope than the
350
- When.
351
-
352
- * _When_ clauses and RSpec _before_ blocks will be executed in the
353
- order that they are specified, from the outermost block to the
354
- innermost block. This makes _before_ blocks an excellent choice when
355
- writing narrative tests to specify actions that happen between the
356
- "whens" of a narrative-style test.
357
-
358
- Note that the ordering between _Given_ clauses and _before_ blocks are
359
- not strongly specified. Hoisting a _When_ clause out of an inner scope
360
- to an outer scope may change the order of execution between related
361
- _Given_ clauses and any _before_ blocks (hoisting the _When_ clause
362
- might cause the related _Given_ clauses to possibly run earlier).
363
- Because of this, do not split order dependent code between _Given_
364
- clauses and _before_ blocks.
365
-
366
- ## Natural Assertions
367
-
368
- **NOTE:** <em>Natural assertions are currently an experimental feature
369
- of RSpec/Given. They are currently disabled by default, but can be
370
- enabled by a simple configuration option (see "use_natural_assertions"
371
- below).</em>
372
-
373
- RSpec/Given now supports the use of "natural assertions" in _Then_,
374
- _And_, and _Invariant_ blocks. Natural assertions are just Ruby
375
- conditionals, without the _should_ or _expect_ methods that RSpec
376
- provides. Here are the Then/And examples from above, but written using
377
- natural assertions:
378
-
379
- ```ruby
380
- Then { pop_result == :top_item }
381
- And { stack.top == :second_item }
382
- And { stack.depth == original_depth - 1 }
383
- ```
384
-
385
- Natural assertions must be enabled, either globally or on a per
386
- context basis, to be recognized.
387
-
388
- Here's a heads up: If you use natural assertions, but fail to enable
389
- them, all your specs will mysteriously pass. This is why the **red**
390
- part of _Red/Green/Refactor_ is so important.
391
-
392
- ### Failure Messages with Natural Assertions
393
-
394
- Since natural assertions do not depend upon matchers, you don't get
395
- customized error messages from them. What you _do_ get is a complete
396
- analsysis of the expression that failed.
397
-
398
- For example, given the following failing specification:
399
-
400
- ```ruby
401
- RSpec::Given.use_natural_assertions
402
-
403
- describe "Natural Assertions" do
404
- Given(:foo) { 1 }
405
- Given(:bar) { 2 }
406
- Then { foo + bar == 2 }
407
- end
408
- ```
409
-
410
- You would get:
411
-
412
- ```
413
- 1) Natural Assertions
414
- Failure/Error: Then { foo + bar == 2 }
415
- Then expression failed at /Users/jim/working/git/rspec-given/examples/failing/sample_spec.rb:6
416
- expected: 3
417
- to equal: 2
418
- false <- foo + bar == 2
419
- 3 <- foo + bar
420
- 1 <- foo
421
- 2 <- bar
422
- # ./examples/failing/sample_spec.rb:6:in `block in Then'
423
- ```
424
-
425
- Notice how the failing expression "<code>foo+bar == 2</code>" was
426
- broken down into subexpressions and values for each subexpression.
427
- This gives you all the information you need to figure out exactly what
428
- part of the expression is causing the failure.
429
-
430
- Natural assertions will give additional information (e.g. "expected:
431
- 3 to equal: 2") for top level expressions involving any of the
432
- comparison operators (==, !=, <, <=, >, >=) or matching operators (=~,
433
- !~).
434
-
435
- ### Caveats on Natural Assertions
436
-
437
- Keep the following in mind when using natural assertions.
438
-
439
- * Only a single expression/assertion per _Then_. The single expression
440
- of the _Then_ block will be considered when determining pass/fail
441
- for the assertion. If you _want_ to express a complex condition for
442
- the _Then_, you need to use ||, && or some other logical operation
443
- to join the conditions into a single expression (and the failure
444
- message will break down the values for each part).
445
-
446
- * Then clauses need be **idempotent**. This is true in general, but it
447
- is particularly important for natural assertions to obey this
448
- restriction. This means that assertions in a Then clause should not
449
- change anything. Since the Natural Assertion error message contains
450
- the values of all the subexpressions, the expression and its
451
- subexpressions will be evaluated multiple times. If the Then clause
452
- is not idempotent, you will get changing answers as the
453
- subexpressions are evaluated.
454
-
455
- That last point is important. If you write code like this:
456
-
457
- ```ruby
458
- # DO NOT WRITE CODE LIKE THIS
459
- context "Incorrect non-idempotent conditions" do
460
- Given(:ary) { [1, 2, 3] }
461
- Then { ary.delete(1) == nil }
462
- end
463
- ```
464
-
465
- Then the assertion will fail (because <code>ary.delete(1)</code> will
466
- initially return 1). But when the error message is formated, the
467
- system reports that <code>ary.delete(1)</code> returns nil. You will
468
- scratch your head over that for a good while.
469
-
470
- Instead, move the state changing code into a _When(:result)_ block, then
471
- assert what you need to about :result. Something
472
- like this is good:
473
-
474
- ```ruby
475
- context "Correct idempotent conditions" do
476
- Given(:ary) { [1, 2, 3] }
477
- When(:result) { ary.delete(1) }
478
- Then { result == nil }
479
- end
480
- ```
481
-
482
- It is good to note that non-idempotent assertions will also cause
483
- problems with And clauses.
484
-
485
- ### Mixing Natural Assertions and RSpec Assertions
486
-
487
- Natural assertions and RSpec assertions for the most part can be
488
- intermixed in a single test suite, even within a single context.
489
- Because there are a few corner cases that might cause problems, they
490
- must be explicitly enabled before they will be considered.
491
-
492
- To enable natural assertions in a context, call the
493
- _use_natural_assertions_ method in that context. For example:
494
-
495
- ```ruby
496
- context "Outer" do
497
- use_natural_assertions
498
-
499
- context "Inner" do
500
- end
501
-
502
- context "Disabled" do
503
- use_natural_assertions false
504
- end
505
- end
506
- ```
507
-
508
- Both the _Outer_ and _Inner_ contexts will use natural assertions. The
509
- _Disabled_ context overrides the setting inherited from _Outer_ and
510
- will not process natural assertions.
511
-
512
- See the **configuration** section below to see how to enable natural
513
- assertions project wide.
514
-
515
- ### Matchers and Natural Assertions
516
-
517
- In RSpec, matchers are used to provide nice, readable error messages
518
- when an assertion is not met. Natural assertions provide
519
- self-explanatory failure messages for most things without requiring
520
- any special matchers from the programmer.
521
-
522
- In the rare case that some extra information would be helpful, it is
523
- useful to create special objects that respond to the == operator.
524
-
525
- #### Asserting Nearly Equal with Fuzzy Numbers
526
-
527
- Operations on floating point numbers rarely create numbers that are
528
- exactly equal, therefore it is useful to assert that two floating
529
- point numbers are nearly equal. We do that by creating a fuzzy number
530
- that has a looser interpretation of what it means to be equal.
531
-
532
- For example, the following asserts that the square root of 10 is about
533
- 3.1523 with an accuracy of 1 percent.
534
-
535
- ```ruby
536
- Then { Math.sqrt(10) == about(3.1623).percent(1) }
537
- ```
538
-
539
- As long as the real value of <code>Math.sqrt(10)</code> is within plus
540
- or minus 1% of 3.1623 (i.e. 3.1623 +/- 0.031623), then the assertion
541
- will pass.
542
-
543
- There are several ways of creating fuzzy numbers:
544
-
545
- * <code>about(n).delta(d)</code> -- A fuzzy number matching the range
546
- (n-d)..(n+d)
547
-
548
- * <code>about(n).percent(p)</code> -- A fuzzy number matching the
549
- range (n-(n*p/100)) .. (n+(n*p/100))
550
-
551
- * <code>about(n).epsilon(neps)</code> -- A fuzzy number matching the
552
- range (n-(neps*e)) .. (n+(neps*e)), where e is the difference
553
- between 1.0 and the next smallest floating point number.
554
-
555
- * <code>about(n)</code> -- Same as <code>about(n).epsilon(10)</code>.
556
-
557
- When the file <code>rspec/given/fuzzy_shortcuts</code> is required,
558
- the following unicode shortcut methods are added to Numeric to create
559
- fuzzy numbers.
560
-
561
- * <code>n.±(del)</code> is the same as <code>about(n).delta(del)</code>
562
-
563
- * <code>n.‰(percentage)</code> is the same as <code>about(n).percent(percentage)</code>
564
-
565
- * <code>n.€(neps)</code> is the same as <code>about(n).epsilon(neps)</code>
566
-
567
- * <code>n.±</code>, <code>n.‰</code>, and <code>n.€</code> are all
568
- the same as <code>about(n)</code>
569
-
570
- #### Detecting Exceptions
571
-
572
- The RSpec matcher used for detecting exceptions will work with natural
573
- assertions out of the box. Just check for equality against the
574
- <code>have_failed</code> return value.
575
-
576
- For example, the following two Then clauses are equivalent:
577
-
578
- ```ruby
579
- # Using an RSpec matcher
580
- Then { result.should have_failed(StandardError, /message/) }
581
-
582
- # Using natural assertions
583
- Then { result == have_failed(StandardError, /message/) }
584
- ```
585
-
586
- ### Processing Natural Assertions
587
-
588
- When natural assertions are enabled, they are only used if all of the
589
- following are true:
590
-
591
- 1. The block does not throw an RSpec assertion failure (or any other
592
- exception for that matter).
593
-
594
- 1. The block returns false (blocks that return true pass the
595
- assertion and don't need a failure message).
596
-
597
- 1. The block does not use RSpec's _should_ or _expect_ methods.
598
-
599
- Detecting that last point (the use of _should_ and _expect_) is done
600
- by modifying the RSpec runtime to report uses of _should_ and
601
- _expect_.
602
-
603
- ### Platform Support
604
-
605
- Natural assertions use the Ripper library to parse the failing
606
- condition and find all the sub-expression values upon a failure.
607
- Currently Ripper is not supported on JRuby 1.7.2. Charles Nutter has
608
- said that Ripper support is coming soon and may arrive as early as
609
- version 1.7.3. Until then, natural assertions are disabled when
610
- running under JRuby. Never fear, JRuby supports all the other features
611
- of rspec-given and will work just fine.
612
-
613
- ### Further Reading
614
-
615
- Natural assertions were inspired by the [wrong assertion
616
- library](http://rubygems.org/gems/wrong) by [Alex
617
- Chaffee](http://rubygems.org/profiles/alexch) and [Steve
618
- Conover](http://rubygems.org/profiles/sconoversf).
619
-
620
- ## Configuration
621
-
622
- Just require 'rspec/given' in the spec helper of your project and it
623
- is ready to go.
624
-
625
- If the RSpec format option document, html or textmate is chosen,
626
- RSpec/Given will automatically add additional source code information to
627
- the examples to produce better looking output. If you don't care about
628
- the pretty output and wish to disable source code caching
629
- unconditionally, then add the following line to your spec helper file:
630
-
631
- ```ruby
632
- RSpec::Given.source_caching_disabled = true
633
- ```
634
-
635
- Natural assertions are disabled by default. To globally configure
636
- natural assertions, add one of the following lines to your spec_helper
637
- file:
638
-
639
- ```ruby
640
- RSpec::Given.use_natural_assertions # Enable natural assertions
641
- RSpec::Given.use_natural_assertions true # Same as above
642
- RSpec::Given.use_natural_assertions false # Disable natural assertions
643
- RSpec::Given.use_natural_assertions :always # Always process natural assertions
644
- # ... even when should/expect are detected
645
- ```
646
-
647
- # License
648
-
649
- RSpec-Given is available under the MIT License. See the MIT-LICENSE
650
- file in the source distribution.
651
-
652
- # History
653
-
654
- * Version 2.4.2
655
-
656
- * Minor adjustment to natural assertion error messages to better
657
- handle multi-line values.
658
-
659
- * Remove flog, flay and other development tools from the bundle and
660
- gemspec. The Rakefile was updated to suggest installing them if
661
- they are not there.
662
-
663
- * Version 2.4.1
664
-
665
- * Fix bug where constants from nested modules were not properly
666
- accessed.
667
-
668
- * Version 2.4.0
669
-
670
- * Add fuzzy number helper methods (with unicode method shortcuts).
671
-
672
- * Fix bug caused by blank lines in Thens.
673
-
674
- # Links
675
-
676
- * Github: [https://github.com/jimweirich/rspec-given](https://github.com/jimweirich/rspec-given)
677
- * Clone URL: git://github.com/jimweirich/rspec-given.git
678
- * Bug/Issue Reporting: [https://github.com/jimweirich/rspec-given/issues](https://github.com/jimweirich/rspec-given/issues)
679
- * Continuous Integration: [http://travis-ci.org/#!/jimweirich/rspec-given](http://travis-ci.org/#!/jimweirich/rspec-given)