What We Just Learned
Cucumber features are a valuable asset to your company. We’ve seen teams that have ripped out and rewritten big parts of their systems, safe in the knowledge that they had a set of accurate, executable specifications to ensure the new solution worked just as well as the original. To those teams, the features were more valuable than the production code itself. If you’re going to invest in writing Cucumber features, you need to protect that investment by caring for them so that they’re as useful as possible to the whole team. Don’t settle for features that are slow, that fail intermittently, or that are read by only half the team: iron out problems as they happen, and use each problem as a reason to make the tests even better than they were before.
Cucumber may seem like a testing tool, but it’s really a collaboration tool. If you make a genuine effort to write features that work as documentation for the nontechnical stakeholders on your team, you’ll find you are forced to talk with them about details you might never have otherwise made the time to talk about. Those conversations reveal insights about their understanding of the problem, insights that will help you build a better solution than you would have otherwise. This is Cucumber’s secret: the tests and documentation are a happy side effect; the real value lies in the knowledge you discover during those conversations.
Try This
Here are some exercises for you to try for yourself.
Defect Prevention on Your Team
Think of three things that are slowing down your team’s production line. What is the root cause of each? What could you do to change them for the better?
Incidental Details Practice
Here is a scenario, written in a hideously imperative style, riddled with incidental details:
| | Scenario: Create an invoice |
| | Given I am a signed in user with role: admin |
| | And a client "Test Client" exists with name: "Test Client" |
| | And a project "Test Project" exists with: |
| | | name | "Test Project" | |
| | | client | client "Test Client" | |
| | And an issue "Test Issue" exists with: |
| | | project | project "Test Project" | |
| | | name | "Test Issue" | |
| | And a work_unit "Test Work Unit" exists with: |
| | | issue | issue "Test Issue" | |
| | | completed_on | "2011-08-24" | |
| | | hours | "7.5" | |
| | And I am on the admin invoices page |
| | Then I should see "Test Client" |
| | And I follow "Test Client" |
| | And I fill in "invoice_id" with "abc" |
| | And I press "Submit" |
| | Then I am on the admin invoices page |
| | And I should not see "Test Client" |
Start by just trying to work out what’s going on: what do you think this system does? What is the purpose of the scenario? What behavior is it trying to test? Notice how the incidental details are like overgrown weeds, getting in the way of you figuring out what the test is actually trying to do.
Now that you understand the essence of the scenario, rewrite it in your own words. You should need much fewer steps, but you might want to consider using more than one scenario.
Now that you’ve rewritten the scenario in a more declarative style, can you spot the crucial Then step that was missing from the original scenario?
Footnotes
- [18]
- [19]
- [20]
- [21]
- [22]
-
This term comes from the excellent paper “Writing Maintainable Acceptance Tests” by Dale Emery: http://dhemery.com/pdf/writing_maintainable_automated_acceptance_tests.pdf.
- [23]
- [24]
- [25]
- [26]
- [27]
- [28]
- [29]
- [30]
- [31]
- [32]
- [33]
-
Toyota Production System: Beyond Large Scale Production [Ohn88]