Given, when, then. The 3 parts of a software test.

Let's talk about Gherkin.

Yes, the language designed to describe application use cases naturally.

In essence, a use case description consists of three parts called Steps: Given, When, Then

Let's talk about Cucumber. Yes, the tool that allows you to turn Gherkin steps into executable tests. It is extremely useful when learning how to design new tests.

And why? Because those three little words are literally how tests work.

What is the meaning of Given, When, Then?

Given, When, Then, in software testing, means the 3 steps of a test.

• Given: in what situation do we want to test the functionality? What preconditions do we start from?

• When: what user action do we want to test?

• Then: what is the expected result?

It’s easiest to look at an example:

Given that the user has some product in the cart
When the user proceeds to purchase
Then the page will show you the payment gateway

And here's the secret: this structure is not only the basis of all good tests, but of all computer science!

The origin: Arrange, Act, Assert

In the beginning God created the heavens and the earth. But since the sky kept falling, he also created unit tests. Four patches and a rollback later, everything is more or less stable.

There is a mantra in the world of unit tests: Arrange, Act, Assert.

Example time:

describe("Shopping cart", () => {
    it("updates the total value when adding a new item", () => {
        // Arrange
        let cart = new Cart();
        cart.add(potatoes);
        let initial_total = cart.total();

        // Act
        cart.add(elephant);

        // Assert
        assert.equal(cart.total(), initial_total + elephant.price);
    });
});

So we understand the different steps in the following way:

• Arrange: we organize what is necessary to obtain the starting point for our test.

• Act: we make the function call or calls that we are testing

• Assert: we verify that the behavior of the function corresponds to what is expected

These three simple steps correspond to best unit test practices and, as we can see, they are very similar to Gherkin's Given/When/Then.

This fact is pure coincidence and definitely has no relation to how computers work… Right?

Finite State Machine

Let's talk about the theory of computation. No, please, don't run away, seriously, this is interesting.

Today's computers are responsible for performing computable operations. What is a computable operation? Something that a Turing Machine can solve.

What is a Turing Machine? Basically a Finite State Machine. And why do I care about all this?

See how we represent a state machine:

Each circle represents a state the machine can have, and each edge represents a transition it can make to another state. And if we look at the transitions of the machine (that is, the changes that occur and, therefore, its functionality) we could describe them as follows.

1. Initial state

2. Chosen transition

3. End state

And if we wanted to check that a transition (functionality) behaves as it should, we would do something like:

1. Arrange: we go to the initial state

2. Act: we execute the transition

3. Assert: we check that we are in the final state

Or put another way:

Given that we are in the initial state
When we execute the transition
Then we come to the final state

A test in three parts

We can call them anything we want, but in the end, in order to perform a good test, it is important to have the three aspects mentioned be well defined and clear.

If we don't define the initial state of our test correctly, we may have to deal with unexpected side effects that come from the state of the application.

If we do not define the action that we carry out correctly, we may not exactly reach the final state we want.

If we do not define the final state correctly, we can wrongly believe that the test has succeeded or failed.

So whenever you write a new test, follow the following checklist:

1. What state do I need my application to be in to perform this test? Write it.

2. What exact action do I want to check? write it down

3. How can I ensure that the result of the action takes me exactly to the state I expect? Write it.

4. Make sure that the three previous steps are clearly visible and understandable in your test.

The next person who reads your test (which might be yourself when you forget anything you’ve done 3 months prior!) will thank you forever.

Now that you know why there are 3 parts to a test, find out if your tests are bad, on our blog.