Mind the step definition: 10 reasons to take part in cucumber steps.

Step definitions are an important part of the BDD process with Cucumber. They are the representation of the specifications in code and instructions for cucumber on what to do. They are composed of a regular expression and a piece of code. While Cucumber reads through the Gherkin specifications if it finds a matching regex it triggers the code associated with it. Writing Step definition is coding and it creates overhead especially at the beginning of projects or when automating specifications for the first time. It can therefore be tempting to delegate the task to testers, junior developers or even external consultants. Please find below, 10 reasons why to not do so.

• The quality of the code that drives development should be of production quality

The value of automated specifications comes from the confidence that both business people and developers have in them. A 'test' passing must mean to business people that the feature is functional and to the developer that it is time for refactoring. Any doubt would trigger manual checking making the test rather useless. Brittle or buggy automation code is a recipe for failing to implement Acceptance Testing. Test code has to be maintained just like production code; in particular it has to be refactored and therefore benefits from unit tests.

• Design for testing

The easier it is to plug automated tests in the software in development the better will be the quality of the tests and therefore the better will be the final product. The person who writes the step definitions must have the ability to take design decision.

• End to end tests vs. in-process test

End to end tests are very useful because they cover the entire stack but they can be brittle and slow. The person who writes the step definitions should be able to find the right balance between both end to end tests and in process tests so they are manageable and the confidence in them remains high.

• It is better to write automation code in the language of the application

There are reasons why Cucumber has been ported to different platforms (ruby, JavaScript, .net, Perl...): skills, implementations, in process acceptance testing. The person who writes the step definitions must be fluent in the language of the SUT (System Under Test) to be able to implement in process tests.

• While writing step definition Developer starts visualizing the domain model

Automated specifications drive the development and the design. While writing step definitions developers think of the domain logic. Classes and methods will be the same in the production code than in the test code.

• Retrofitting Acceptance tests/regression tests in an existing system

When working from the outside in the tests are written first and should therefore always have a clear format. When retrofitting tests in an existing system it is sometimes more difficult to write the tests, they can have a lot of preconditions and support code. This is usually the sign of a missing abstraction in the production code. The person who writes the step definitions should be able to identify this problem and address it.

• In the BDD cycle Unit test and acceptance test are independent but nonetheless related

Write a failing Acceptance Test, watch it fail, write unit tests, make them pass and refactor until the Acceptance test pass. Typically the unit tests will be at the level of each step of the specification. While writing step definition developers can already think of the implementation of their unit tests.

• Collaboration

BDD is all about collaboration. When developers write step definitions it is an opportunity for them to ask for further clarifications if necessary.

• Knowledge of the SUT and access to its components is important

For instance it may be interesting in some cases to set the context in the database. The person who writes the step definition will need the appropriate access rights.

• If testers wanted to code…

…they would be developers.

Does this mean testers should not write any automated test? No. It means testers can do what they do best, exploring, looking for edge cases and implementing them using the step definitions written by the developers for the happy path as a template. Furthermore they must manage the tests and decide what tests should be part of the regression tests suite. A pair Tester/Developer is ideal for writing step definition; it leads to collective test ownership.