Unit testing is a popular approach for testing software, but mostly for the wrong reasons. It’s often touted as an effective way for developers to test their code while also enforcing best design practices, however many find it encumbering and superficial.
It’s important to understand that development testing does not equate to unit testing. The primary goal is not to write tests which are as isolated as possible, but rather to gain confidence that the code works according to its functional requirements. And there are better ways to achieve that.
Writing high-level tests that are driven by user behavior will provide you with much higher return on investment in the long run, and it isn’t as hard as it seems. Find an approach that makes the most sense for your project and stick to it.
Here are the main insights:
- Think critically and challenge best practices
- Don’t rely on the test pyramid
- Separate tests by functionality, rather than by classes, modules, or scope
- Aim for the highest level of integration while maintaining reasonable speed and cost
- Avoid sacrificing software design for testability
- Consider mocking only as a last resort
There are also other great articles about alternative testing approaches in modern software development. These are the ones I’ve personally found really interesting:
- Write tests. Not too many. Mostly integration (Kent C. Dodds)
- Mocking is a Code Smell (Eric Elliott)
- Test-induced design damage (David Heinemeier Hansson)
- Slow database test fallacy (David Heinemeier Hansson)
- Fallacy of Unit Testing (Aaron W. Hsu)
- The No. 1 unit testing best practice: Stop doing it (Vitaliy Pisarev)
- Testing of Microservices at Spotify (André Schaffer)