And What?

Cucumber allows us to write feature files to express the specification of our system. The lines in the file contain statements in the Given/When/Then format…


There’s also but and and.

First Principle

A single scenario starts with a collection of Given statements, describing the initial state of the system, or the behaviour of external dependencies, or the state of the actors in the scenario.

Then the scenario goes on to describe an event in a series of When statements.

Finally, the scenario describes the observable outcome in a series of Then statements.

But What about And and But?

The ands and the buts are sensible ways to chain together the multiple statements of the same type. They’re still describing things that are Given/When or Then.

Is It Always This Way?

There are notable exceptions. Sometimes there’s no need to mention the Given or When parts of a spec. Somethings things just are.

Very occasionally, for incredibly naughty reasons, a scenario may represent something that occurs between two use cases, and maybe this ends up going back from a Then to almost a fresh set of Whensteps… but that should really be considered as an outlier and avoided.

What of the Annotations in Java?

In my own test coding standard, the @And annotation is banned. This is because you lose something. Example:

@And("^the buffer is emptied$")
public void theBufferIsEmptied() {

The above looks like a perfectly innocent bit of glue. When the buffer is emptied, we tell our buffer object to clear itself.

Except… what of the universal cucumber code review rule? Steps should not lie? Is this one a liar?

What if the feature file was:

Given the buffer is full
When the clear buffer alert is broadcast
Then the buffer is emptied

Hang on a minute… the the buffer is emptied is being used as a Then in the spec…? That means it should contain an assertion:

@Then("^the buffer is emptied$")
public void theBufferIsEmptied() {

If something marked Then does not look like an assertion (as the @And version certainly did not), then at a glance we can spot that there’s something funny going on in the way the automation code has been put together.

Take Home Messages

  • Clearly we should avoid ambiguous language in the first place
  • Make the steps clearly represent their Given/When/Then ness because you can spot errors better
  • Make sure a test fails for the right reason before going on to create the code that makes it pass
  • Be wary of green tests unless you know why they’re green
  • Continue to write feature files in as natural a way as expresses the specification of the system

Feature files are in an unnatural natural language that can be hard to write. They are an excellent way to communicate with everyone about the nature of the systems we are building and we should seek to perfect them and the code underneath them that serves to execute our tests.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s