Filed under: Cucumber, — Tags: Gherkin — Thomas Sundberg — 2017-10-26
When you do Behaviour-Driven Development, BDD, you start with a conversation. The conversation leads to concrete examples that can be used as acceptance tests. When you implement the acceptance tests, it may be the case that you can finish the development shortly after. Unfortunately, it may also be the case that the development will take some time. Maybe even a few days.
How do you handle the case where you commit your changes to your version control system and your continuous integration server build the system but the acceptance tests doesn't pass just yet?
There are a few different solutions you can use:
Keeping work in progress on your local development machine is obviously possible. But if you are working in a team, you should probably share you work early.
Not committing your code is unprofessional an a path to a bad place. At least a bad place from my perspective.
A lot of people think that branching and merging is a the way to go. It will allow you to commit and share your work. The branch will not be built by your continuous integration server, unless you create a specific job for this branch.
From my perspective, this a habit that makes the life as a developer unnecessarily complicated. Things like continuous integration get cumbersome. Creating a build job for this branch indicates that this might be a long lived branch. Long lived branches are great if you like pain when merging your work later. If you don't enjoy pain, you avoid long lived branches. I solve this by avoiding branches as much as possible.
It is common to see people comment out steps, or even the entire scenario, they don't want to execute. This may work, but the risk is that you forget to enable steps you want to execute. You now think, that's only those who don't know what they do that would forget such a thing. Unfortunately, I have seen examples of developers who really know what they do to making that kind of mistakes. We are only humans and it is easy to make silly mistakes.
Is there a solution to this problem? There are at least two good solutions. The best is to work in small batches that you can finish before it is time to commit and share your work. This is, however, not always possible.
The second best solution is to mark the scenarios you aren't done with yet somehow. This way they can be used during development but are not executed during the continuous integration build. The mechanism available in Cucumber is called tags.
A tag is a single word that begins with @ that you mark a scenario with. An example may look like this:
Feature: Serve coffee
@wip
Scenario: Buy last coffee
Given there are 1 coffees left in the machine
And I have deposited 1 EUR
When I press the coffee button
Then I should be served a coffee
In this example, the scenario Buy last coffee has been tagged with wip to indicate that this is work in progress, wip.
The tags are arbitrary, you can call them whatever you want. The only limitation is that a tag can't contain a space. I choosed wip as this is a common abbreviation for Work In Progress.
To build the project and not execute scenarios tagged @wip I have to specifically tell Cucumber to ignore these tags. It is done by passing options to Cucumber. I also have the option just to run the scenarios tagged with @wip.
Building using Maven with mvn test -Dcucumber.options="--tags @wip" will build the scenarios tagged @wip and only those.
The negative case, ignoring the scenarios tagged @wip is done ny negating the tag like this: mvn test -Dcucumber.options="--tags not@wip"
A scenario can have more than one tag. This give you the possibility to divide your scenarios along different axes. Some are perhaps slow and could therefore be tagged @slow. Some are perhaps part of your smoke test suite and thus are tagged @smoke. The limitation is the sky, your fantasy, and your needs.
Tags can also be used in your step implementations. The Before and After hooks support tags. This is out of scope today. But if you are interested, you now know what to look for.
I would like to thank Malin Ekholm for proof reading.
RSS