Talk from Suffolk Developers, 30 March 2015.
Notes:
What it is
What it's for
How to get the most out of it
Cucumber.js, Cucumber-JVM, SpecFlow (.NET), Behat (PHP), and others
Plain text description of expected behaviour
Just text for information
Format optional (see as a/I want to/so that)
Can be nothing, or a whole page (Relish)
One or more scenarios per feature
eg checkout feature: check out with card, with paypal etc
First line just descriptive again
Steps are meat of scenario
Text is matched to executable step definitions (see later)
Given: set up preconditions
When: do the thing you’re describing
Then: check you got the expected result
Also And, But, *
A more realistic feature
When we run it …
Steps initially undefined
Provides skeleton definitions to get you started
Regular expression with capture groups
Used to be built-in steps for common web actions …
web_steps.rb – “training wheels” but often overused
Deprecated then removed
Why is it bad? …
Leads to scenarios like this (one of mine) – loads of them!
212 feature files, 1143 scenarios, 9210 steps, 45 minutes.
Lots of detail in the features, hiding what’s important
What happens when you show these to customers/business/stakeholders?
Back to web_steps example
So how can we improve this? …
Replace procedural with declarative
Just show what’s important
Of course we now have to define our own steps …
Using Capybara – simple DSL
Once you start talking about the feature in simple declarative steps, it’s easier to uncover other pieces of behaviour
Important to get words right (ubiquitous language) – same terms from business people down to classes and methods
If everyone uses the same language, there are fewer misunderstandings, and the code’s easier to understand
Of course you can go too far!
Not just developers – whole team!
Developers, testers, customers, users, business analysts …
“… web applications” … speaking of which …
Selenium-webdriver, using Firefox
Headless browser (eg Poltergeist) is 4–5x faster
For non-javascript (in Ruby), use rack-test (twice as fast again)
Tag scenarios which need javascript
Not just web.
Aruba: command line apps
Calabash: Android and iOS
A feature with several scenarios
Duplication!
In this case just one step, but could be more
Extract to background
Runs before each scenario
Another example – different kind of duplication
(lots of similar steps)
Single step with a table
Table is passed to step definition for parsing
Yet another kind of duplication
Several similar scenarios
Convert to scenario outline
Executes scenario once for each row
Substitutes values
Use sparingly!
Ubiquitous language doesn’t have to be English!
Comes with support for ~40 languages
Easy to add more
Example from the documentation
Some slightly less serious languages!
Also pirate, Texan, Scouse, Australian
Keep everything organised!
Already seen techniques for features – what about step definitions
Some step definitions from our earlier login example
These share a lot of code
Field names etc could be repeated all over
All need to be modified if app changes
Extract to a method in a module
Include the module in cucumber’s ‘world’
In general aim for small step definitions calling methods in well-organised modules
See also Page Object pattern
Common confusion: acceptance tests have to be end-to-end
eg do everything through a web UI
Makes them slow!
Alastair Cockburn’s ‘hexagonal architecture’
Puts business logic at the centre, with adapters for UI, persistence etc
Test business logic directly (plus limited E2E confidence tests)
Like TDD, cucumber’s not really primarily about testing
Helps develop a shared understanding of how the system should behave
Reduce unused features and rework
Cucumber features provide a framework for simply documenting the shared understanding of behaviour
… and make that documentation executable to prove it’s still true
BDD: driving development with concrete usage examples based on conversation with customers and users
Good books from PragProg
Hopefully passed!
Questions?