Cucumber is an execution framework for a specification language. It’s not meant to be a testing language, but it’s used for creating test automation.
Cucumber lends itself best to situations where there are some real-world actors interacting and achieving some sort of outcome. It’s especially useful when it can be written from the point of view of the user.
Given Sarah is a premium club member When Sarah logs into the homepage Then she sees the premium club member call to action
Though this may be talking about the screen, it’s also talking in the language of the users and product. This is a comfortable specification.
Who Is The User of a Back End?
Let’s say we want to write API tests in Cucumber for our back end? This gives us a few issues, like the fact that it’s a lower-level interface that’s not necessarily in user language, or the fact that we have to track the state of the requests we make, because we can’t just talk about what’s on the screen.
So should we?
Is Cucumber the wrong tool for writing API tests?
The answer to this is in whether we think the back end has a specification that can be expressed in a human readable form.
Do We Think Our Backend Has A Specification…?
Let’s admit that whatever the specification is, it’s in a more technical language than feature-level acceptance tests that might relate to business processes of which this back end is just a component.
Some of the problem here is writing. We want to express in a succint form the expected/desired behaviour of a system. This is where we need to resort to the 1-2-3 of writing. Every story has a start middle and end.
How would you explain to the person who pays for your work what a given API’s purpose is?
Well, this API is the one which produces a user sign on certificate for a user based on receiving their credentials, assuming that the user is known to the credentials database, otherwise it doesn’t…
Ok.. there’s blether in that, but at least it sounds valuable. Can we 1-2-3 it?
For a known user, providing the credentials will result in a certificate.
And in Gherkin:
Given Sarah is known to the credentials database as "sarah" with password "s4r4h" When Sarah's sign-in request is submitted as "sarah", "s4r4h" Then a certificate is returned And the certificate contains the name "Sarah"
Where To Start?
The manufactured examples are easy… how can you get started with this?
Here are some ideas:
- Draw a diagram of the service/services that you’re trying to test
- Identify which things on the diagram are the target of testing and which things are either:
- The consumer of the service
- The service’s dependencies
- Consider a data flow through the service:
- How can you make it start?
- How would you observe its behaviour
Now we understand:
- External triggers/clients of the service
- Things the service returns
- Things the service needs to happen to support it
- Things the service does to the outside world
Our specification should be in the above terms.
Our test design should be able to explain how the automation will consume the service as a client, supply any dependencies, and observe the side effects and responses of the service.