Handling Integration Tests in a CI pipeline
Tags: testing, devops, entityframework, dotnet
Published: 2019-11-06 15:23:38

<p>Integration Tests are a fundamental block of every project. And as such, they deserve a special treatment in the CI pipeline.</p>



<p>First of all, let’s make a clear distinction between <strong>unit </strong>and <strong>integration</strong> tests.</p>



<h4>We <a rel="noreferrer noopener" aria-label="discussed already (opens in a new tab)" href="https://www.davideguida.com/unit-integration-end-to-end-tests-do-i-need-all-of-them/" target="_blank">discussed already</a> on my blog about this, but I would like to do a quick recap.</h4>



<p>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 <strong>unit </strong>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 <a href="https://nsubstitute.github.io/" target="_blank" rel="noreferrer noopener" aria-label="NSubstitute  (opens in a new tab)">NSubstitute </a>when I’m working in C#.</p>



<p>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.</p>



<h4>Now, with Docker is relatively easy to setup a developer’s machine with something very similar to the production environment. </h4>



<p>We can spin up databases and microservices with few config files and run the tests directly from our local machine.</p>



<p>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 <a href="https://en.wikipedia.org/wiki/Continuous_integration" target="_blank" rel="noreferrer noopener" aria-label="Continuous Integration (opens in a new tab)">Continuous Integration</a>.</p>



<p>There are several options for <strong>Continuous Integration</strong> available online, all with pros and cons. <a rel="noreferrer noopener" aria-label="CircleCI  (opens in a new tab)" href="https://circleci.com/" target="_blank">CircleCI </a>and <a rel="noreferrer noopener" aria-label="Travis CI (opens in a new tab)" href="https://travis-ci.org/" target="_blank">Travis CI</a> are just an example. They can connect to an existing repository and run the CI pipeline after every commit. </p>



<p><a rel="noreferrer noopener" aria-label="BitBucket  (opens in a new tab)" href="https://bitbucket.org/" target="_blank">BitBucket </a>and <a rel="noreferrer noopener" aria-label="GitHub  (opens in a new tab)" href="https://github.com/actions" target="_blank">GitHub</a> move a step further as they can also host your repositories so you can rely on just single platform.</p>



<p>I’ve been using <a rel="noreferrer noopener" href="https://about.gitlab.com/" target="_blank">GitLab</a> 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.</p>



<p><a href="https://www.davideguida.com/handling-integration-tests-in-a-ci-pipeline-part-2-an-example/" target="_blank" rel="noreferrer noopener" aria-label="Next time (opens in a new tab)">In another article</a> I’m going to show a very simple <strong>.NET Core</strong> application with <strong>Entity Framework 3</strong> . We will also discuss how we can write <strong>integration tests </strong>that can run locally and as part of a CI pipeline.</p>