Integration Tests are a fundamental block of every project. And as such, they deserve a special treatment in the CI pipeline.
First of all, let’s make a clear distinction between unit and integration tests.
We discussed already on this blog about this, but I would like to do a quick recap.
Unit tests are responsible of testing components in complete isolation. Dependencies have to be replaced with mocks and the whole test suite should take few seconds to run. If you have a unit test that takes more than 1-2 seconds, then you might want to take a deep look at the code. There are several good libraries for creating stubs and mocks available in every language. Personally I use NSubstitute when I’m working in C#.
Integration tests instead are responsible of ensuring that the access to external systems works as expected. Database writes and reads, calls to APIs, basically every I/O operation your application is performing.
Now, with Docker is relatively easy to setup a developer’s machine with something very similar to the production environment.
We can spin up databases and microservices with few config files and run the tests directly from our local machine.
But this is just the first step: once committed to the source code repository, we need to ensure that the code is always in good shape. Hence, we have to execute the tests also on whatever platform we’re using. This is one of the fundamental steps of Continuous Integration.
There are several options for Continuous Integration available online, all with pros and cons. CircleCI and Travis CI are just an example. They can connect to an existing repository and run the CI pipeline after every commit.
I’ve been using GitLab instead for the last year in my daily job. It’s quite good…although sometimes I think that Swiss-army-knives are not the answer to everything.
Next time I’m going to show a very simple .NET Core application with Entity Framework 3 . We will also discuss how we can write integration tests that can run locally and as part of a CI pipeline.