stack twitter tryhackme rss linkedin cross

Wilco van Esch

Skip to main content

Search results

    No, you shouldn't NOT use unit tests

    How valuable are unit tests?

    After more than a decade of "they're useless!" and "they're essential!" articles and discussions, we're no closer to an answer. That's not because it's one of those nuanced practices where we need to consider the context of the application, the codebase, the specific functionality, the team's skill, the business objectives, the stage the business is in, and so on. We should, but that's not where people disagree. Rather they seem to disagree due to miscommunication.


    A unit does not necessarily mean a class or a function or method. In a sociable unit test, you can test a functional unit that might be a class method which depends on several methods in other classes instead of mocking them out.

    In some discussions, two people have been arguing for that exact kind of test that's fast and meaningful and maintainable and easy to debug while one of them calls it integration testing and the other calls it unit testing.


    Sometimes the argument against unit tests is that they don't give sufficient confidence about the system. That's not what unit tests are for. That's why you don't just have unit tests, but tests at all levels depending on the balance of how much information they give you about the system versus how costly it is to gain that information and act on it.

    Return on investment

    One person will claim unit tests are a waste of time and another that they've saved them so much time. Who is right? Well, both of them.

    You can easily make unit tests a maintenance horror if you write as many of them as you can. You can also make them save time by writing them for functional logic that has to work and for coverage of many permutations of input.

    You can make unit tests a waste of time if you don't know what a good test looks like. You can make them save time by writing fast, isolated, deterministic, highly readable tests for loosely coupled, testable code.


    I see unit tests as valuable and I think anyone would if they shared an understanding that unit tests can be light integration tests, if they understood the comparative value versus other types of testing, and if they've come to understand the difference between a good unit test and a bad unit test.

    However, I suspect that in another decade the same argument will still be had.