How to write an integration test?

Any product needs to keep constantly high quality on the long run and integration tests are the tool you need to go towards that path.

Inside that article I’m gonna focus on the higher process rather than the tools themselves. The idea here is to focus on the questions you might ask yourself during the process of creating tests so then you can advance by your own.

The cost of a bug

First of all I would like to remind you what is a bug and why it is important to test to avoid them.

We use to say that the devil is in the details and in software engineering this is more than true as most of the bugs reside there.

However, did you ever wondered what was a bug?

You might be tempted to answer that it is an incorrect state within the application but you would be surprised as this definition is wrong and it is instead the definition from an incoherent behavior of the application.

A bug is indeed an incoherent behavior but not all incoherent behaviors are bugs.

What makes the difference is that the bug needs to be visible from outside and it is really important to understand that to prevent writing useless tests that would be asserting than an incorrect behavior not being a bug is not existing.

Then once we are on the same basis about what is a bug the second question you might ask yourself is why letting them flow and let the users report them.

For a simple reason, have you ever had to comeback on a task you finished by the past? Isn’t it annoy? You have to get back into it, try to remember things, in other terms you will be slower and that slowness has a cost.

This is a perfect example why the later a bug is discovered the highest is the cost to fix it.

This cost is why we want to catch bugs early while they are still cheap to fix.

Test you done the task not you worked

One of the sentences I hate the most about testing is “Have you tested your code?”.

Most developers won’t like this sentence cause they consider tests as a burden they are forced to handle but I don’t like that sentence for another reason: this sentence is totally wrong !

Hell is paved with good intentions and this is one of them.

When you are saying this to another developer you mean good toward them by telling them to implement tests but what you don’t see is that you are also leading them into a mistake.

When testing you should never test your code but your expectations.

This is due to how tests are actually working they aren’t testing your program is exempt from bugs but it is in fact checking if there is a gap between what the test expects and your code.

If you base the test on the code then you should find no bugs as they are both matching and that even if your code didn’t meet the project expectations !

So what should we test instead?

We should test your project expectations and base your tests on them and never consider the implementation when testing.

Now you might be confused on how to test the project expectations and what they are and this is why I would like to introduce you to a new friend, acceptance criteria.

Follow the guidelines

Nothing is worse than being in front of a blank page without any idea of what comes next.

And be sure about one thing when you begin to learn testing you will face that feeling often.

However, I got good news for you there is a way to reduce that feeling by writing specifications in a special way which is called acceptance criteria.

An acceptance criteria is a simple sentence describing an atomic behavior from the application so that way it is easy to test as now we have precise instruction for each of your scenarios as there will be an acceptance criteria describing it precisely.

Have some flow

Unlike what beginners think there is an order for writing tests and code.

Not that it won’t work if it is not done properly but it will be harder and more error prone.

For that a good flow which is also really trendy is Test Driven Development.

However, that practice is also dogmatic and as a beginner it is easy to get lost between rules to apply.

This is why it is important for beginners to comeback to the essentials to make sure to understand the process.

It is the most important and there is no shame with not starting with a perfect process, Rome didn’t build in one day and so will your testing skills.

Instead it is better to focus on the 3 rules from tests driven development and apply them the way that suits you the best.

The first rule is to implement the test before writing any code.

This is make sure you are not testing your code and that you are basing them on your acceptance criteria.

The second rule is to make sure that the test fails before you wrote any code.

In a small project that might won’t make much sense but when the project state to scale then it is hard to track if an issue can be tackle by another. This check is here to make sure the job wasn’t done previously and that implementing that code will be effective work for the company.

The last rule is that all tests should pass once you finished writing code.

Making sure every tests are passing allow keeping track of that matters for us inside the application and make sure that we won’t break anything while refactoring or adding new features in the future.

Only AAA quality

To implement a scenario we got acceptance criteria describing each one of them but how to pass from a sentence to the actual code?

The first step is to make sure that the acceptance criteria is complete and for that we will have to understand what are the 3 component of a test.

First we will arrange the state from the application to make sure at each run we have a certain state precised inside the acceptance criteria. The idea here is to have the exact same state each time we run the test to be make sure we can reproduce it.

The next step is to act the logic we want to test.

Finally the last step is to assert that the new state is the one we expected otherwise we make the test fail.

As you maybe guessed it if you know the framework AAA we each step is following a step from the framework and to have an acceptance criteria well defined it needs to follow this 3 steps too.

It is not always simple to detect rapidly a pseudo-code language called Gherkin has been designed.

In that language each acceptance criteria should include at least 1 time each of theses keywords:

• Given: This keyword is linked to the arrange step and is here to define the initial state.
• When: This keyword is here to define which logic needs to run.
• Then: This keyword is linked to the assert step and make sure the test is asserting the final state is the one expected.

Conclusion

Testing is complex however it is possible to achieve effective testing by following some principles and dividing steps well.

First make sure you are not testing your code and that you are testing potential bugs by creating and using some acceptance criteria.

Then respect the 3 rules from test driven development so you have actual make sure you are writing effective code for your company and that you can keep track of what is important inside the application.

Finally to write each scenario you will have to follow the AAA framework making sure you are not forgetting any of the three steps Arrange, Act, Assert.