What and Why to Integration Test
Ever wonder what is integration test? What is the use cases? Or maybe when do you need it? Or do you even need it? This post tries to explain a bit about integration test. Also, the first post in this blog is about integration test. Well because this post also serve as an integration test. What is the integration test anyway?
What is integration test
Before we answer this we need to look at the testing pyramid. In the testing pyramid there is a mention of multiple test stage which is (depending on where you found it) :
- End to End / UI Test
- Integration / Service Test
- Unit Test
If you notice, integration test sat above unit test which means that they depend on the unit test to be succeed before you can start determining whether or not the integration test may succeed. So in simple terms, integration test is an act to verify or integrate multiple module (unit or service or whatever did you call it) that when combined, they work together in harmony. So if your unit test is failing but your integration test is succeeding that's mean you have an invalid integration test. But why you need integration test anyway?
Why you need integration test
As previously mentioned, integration test is meant to integrate multiple module together and verify if they are working together as expected. The module in this context is something like external entity where you simply can't directly test it or when you test it, it depends too much on external state which subsequent run might make it fail.
Now imagine you have a service named blog which handle post listing and creation. The service just generate stored or rendered post, it will store the post to a data store of your choice. You can create a unit test in blog that handle the generation and listing logic until it tries to store it in a data store. However, the data store's storage logic is mocked using mocking library so you won't have to care the about the details. The mocked part now will assume that given certain parameter then it return certain result based on the mocked scenario. However you simply can't trust it will remain like that since software do evolve from time to time. Look at Elasticsearch for example, the indexing syntax may change on major release and your code might stopped working altogether for some reason. Without integration test, you have no way to know that something is breaking since you mocked the data store. So, if we add integration test to our list, we can be sure (at least for the tested part) that if anything goes wrong, the test will notify you first before your customer notify you. You can also integrate integration test to your build pipeline to stop it from continuing when the integration test is failing. After knowing what and why to implement integration, some of you might be wondering on how do you implement integration test?
How to implement integration test
Well, there is multiple way to implement integration test, one of them is using a library or framework that did just that. For example, you can try using Cypress or REST Assured automation test. Some people actually built their own stack just to perform integration test. For example below is how the Cypress show in it's documentation. How install Cypress npm install cypress --save-dev and it's example :
The idea is that you just check if given parameter X then other service should response with result X. Notice the word "should" here means that it literally should return that result without you enforcing it. If it's response is other than that then it should be marked as failing. You should also try to run integration test periodically (maybe every one hour) and for every code change that you deploy so that if anything is breaking or changing it will scream.
Reference
- https://www.pexels.com/id-id/foto/puzzle-jigsaw-3482441/
- https://martinfowler.com/articles/practical-test-pyramid.html
- https://leaddev.com/agile-other-ways-working/demystifying-software-engineering-test-pyramid