Tea-Driven Development

In this blog post, I will reveal a secret to you. A secret that can get you access to free, hands-on BDD coaching from some of the world’s leading experts like Aslak Hellsøy, Mike Sassak, Greg Hnatiuk, Joseph Wilk and even me, Matt Wynne. Yes, that’s right: absolutely FREE.

Would you like to know how?

I’ll give you step-by-step instructions.

1. Point your web browser to the Cucumber issues list.

2. Have a look around. Take your time. Look for issues that don’t already have Code Attached, because we’re looking for an issue that nobody has tried to solve yet. Found an interesting one? Good.

3. Fork the Cucumber repository to your Github account.

4. Now comes the hard part. You need to write a failing test for the issue you found. Start by writing a scenario that describes the way the code should behave once the issue has been fixed. Try to not to just create a file called ‘features/fixissue234.feature‘ but instead try to slot your scenario into the existing features as extra detail about that particular aspect of the system. You might need to create a new feature file, but try to name it according to the behaviour it describes, rather than the bug it tests. Look at the other features for examples of how to write your scenario. Try to use a declarative style where possible.

5. With your scenario written, it’s time to submit a pull request.

6. This is where your FREE BDD coaching will begin. One of the Cucumber team will see your pull request, and will be delighted to offer you feedback on your scenario. You don’t have to wait for the feedback though, you can go ahead and start to get your scenario running.

7. Keep pushing. Every time you make progress, getting the steps of your scenario to actually run against Cucumber, push to your fork and the pull request will be updated automatically by Github’s legions of octocats. Your FREE BDD coach will keep encouraging you with comments and feedback. Now comes the hard part.

8. Once you have the scenario running, you’ve got the bug trapped: it’s time to fix it! Again, your FREE BDD coach will be in your corner. Ask questions about the design of the existing cucumber code, about your code, write specs to isolate behaviour further, and let your FREE BDD coach guide you. Before you know it you’ll have fixed the issue, and your name will be emblazoned in the codebase forever more.

This is a great way to get access to some very experienced and friendly software developers and feel good about giving something back to the community. Many wise software craftspeople have already discovered this secret. Isn’t it time you joined them?

And did I mention that it’s FREE?

I sometimes get asked whether it’s possible to use Cucumber to test performance. The way to do it is to specify concrete examples of scenarios that the system will find itself in under stress. For example:

Given there are 100,000 users registered on the system
When I create a new account
Then I should be taken to my dashboard within 5ms

or

Given 1000 users are hitting the homepage simultaneously
Then each user should get a response within 2ms

Talking through these kinds of scenarios with your stakeholders will help you to understand where the boundary is for what they consider to be acceptable performance. You might find it hard to get them to be this specific at first, but help them understand that what you’re doing is drawing a line in the sand for the minimum acceptable performance – most of the time the application may be much faster than this. Now you have agreement about this, the next step is to work out how to automate these scenarios, by calling your load testing tool of choice from the Cucumber step definitions.

The key thing is to have Cucumber delegate to the stress testing tool, rather than the other way around. A common mistake people make is to simply point JMeter at existing Cucumber scenarios, but this doesn’t give you the benefit of having the parameters of the performance test documented in readable Cucumber scenarios.

These are not normal kinds of Cucumber tests. You would need to run these against an environment that’s representative of your production hardware, whereas normal behaviour scenarios could be run against any environment. It’s useful to create these scenarios early on during the project and run them against every build so they become constraints that every build must meet as the project progresses.