Is it right to skip unit testing and go straight writing integration tests if there's no point of testing the unit in isolation?

Question

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.

Answer 1

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);
    }
}

Answer 2

In the real world you will almost never get to 100% test coverage and have all corner cases figured out. So you try to cover as much as you can with both unit and integration tests.

The fact that you see no point in writing an unit test because a module is dependant on a third party source, is because your design probably doesn't allow mocking.

If you have a module that has an external dependency (e.g. file system or database), you should be able to emulate that external dependency, and make it return whatever you like. Then, you will have a perfectly valid unit test, that won't rely on the actual presence of the file or record or whatever, and can be run multiple time.

This usually comes with little design cost and improves testability and modularization quite a bit.

For example, in your Authenticator case, your code should recieve a Connection/Database object and query that, so you can pass it your mock database and let it return valid/invalid datas at will.

Answer 3

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?

This is a false argument. If the sole purpose of the unit is to store and not to validate, the unit test should test just that purpose. Validating what the DB returns is out of scope to this test and should be tested somewhere else. You may be missing a "credential validator".

Part of the test may be however that the unit uses the credential validator before considering itself done.

The formal answer would be that any function that offers nothing to be tested serves no purpose and should not exist.