How to Phrase Back End Tests in Cucumber

Ashley FriezeFebruary 21st, 2020Last Updated: February 19th, 2020

1 521 2 minutes read

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.

Bonus Feature

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.

Published on Java Code Geeks with permission by Ashley Frieze, partner at our JCG program. See the original article here: How to Phrase Back End Tests in Cucumber

Opinions expressed by Java Code Geeks contributors are their own.