Programming Practices – Should You Skip Unit Testing for Integration Tests?

integration-testspatterns-and-practicesprogramming practicestddunit testing

According to Martin Fowler's article,

https://martinfowler.com/bliki/TestPyramid.html

It is advisable to write more unit tests than integration tests. Does this mean ideally that every unit of work must be written with unit tests including all the edge cases? How about if there seems no point in unit testing, for instance, an authentication module which is heavily dependent on what the database will return and whose only operation is to store the authentication user to its singleton instance?

Is it right to skip unit testing and go straight writing integration tests?

There's only but one reason that I can think of why unit test must still be written for the authentication module and that is to introduce an abstraction layer between the domain layer and persistence layer, so that the authentication is not tightly coupled to the chosen ORM and switching ORM will be easier.

Best Answer

In my view integration tests are the most important tests, because they are the ones which tell you if your application actually works when its all put together.

However, they have some downsides

  • they require a running system with all dependencies to test against
  • they are slow to run
  • some tests are necessarily destructive and so cant be run against live environments.
  • they tend to be 'top level' tests. they will tell you something is wrong but not what that thing is.

Unit tests don't have these downsides, you can quickly run hundreds of unit tests on a dev machine without deploying the whole app.

So don't skip unit tests just because you have an integration test and don't skip integration tests because you have unit tests.

One trick you can do to save some code is to make your tests work both as unit and integration by allowing them to mock or not mock dependencies depending on an input or setting.

This allows you to run your tests as unit tests quickly to verify the code. Then as integration to verify the setup and deployment.

Edit : example of how to combine integration and unit tests without code duplication.

public class AuthServiceTests
{
    [TestCase("api.myapp.com/auth", "databaseuser", true, Category="Integration")]
    [TestCase("mock", "mockuser", true, Category="Unit")]
    public void IsUserTest(string target, string username, bool expected)
    {
        //SetUp
        if(target != "mock")
        {
            httpClient = new HttpClient(target);
        }
        else
        {
            httpClient = new MockHttpClient();
        }
        var authService = new AuthService(httpClient);

        var actual = authService.IsUser(user); 
//obvs this might fail if the databases changes in the integration version
//or the db isnt setup right, or the connection string in the api is wrong etc

//the mock one will only fail if the code has a bug of some kind, say it doesnt work with long usernames, or emoticons or something

        Assert.AreEqual(expected, actual);
    }
}
Related Topic