Why you want fast tests

compiling

In my previous posts, I’ve written about how to write good unit tests.

This post is about why your tests should be lightning-fast:

Time for test execution adds up in a CI/CD pipeline. You should keep the execution time of your CI/CD pipeline well below 5 minutes. Time waiting for the CI/CD pipeline to succeed is paid work time with no added value. Even worse: Developers may be bored by waiting and then might start side projects. Then you will have additional overhead for switching tasks.
Only with quick test-code-test turnaround cycles, you can really work TDD style.
In the early days of computers, programmers needed to hack their code into punch cards. Then they handed the stack of punch cards over to an operator. One day later, they got the results of the code. If the code failed to run or the result was wrong, then one whole day was lost. So they needed to carefully think about what the computer will do with their code and check all possible mistakes. As turnaround cycles become smaller and smaller, you do not need to think about what the computer will do with your code in advance: You can just give it a try. Please watch Bret Victor’s↗ video “Inventing on Principle”↗. Have you really watched it? If you don’t have time, please just watch 3 Minutes↗.

Still, you need to think about possible errors later, but at first, you can just play. What if your daily work would be like “see the wind in the blossoms”? How fast could you go?

Conclusion:

The faster your test is, the better.

Popular misconceptions

Wrong: “Acceptance tests are not unit tests.” Correct: Acceptance tests can be unit tests, but acceptance tests can also be executed on a higher level of the test pyramid. If you can test the business rule on the unit test level, then do it. Make acceptance tests as fast as possible.
Bad: “Acceptance tests use selenium webdriver, because they are done by a different QA team.” In this case you’re essentially sacrificing developer happiness, software development speed and money for your idea of a organization structure. Good: Put test engineers into the development team, let them work together closely with developers in a cross functional team.
Worst: “Acceptance tests are done manually by people during a special testing phase before release.” Releases are done quarterly or even less frequently by a fixed schedule.

Popular misconceptions

Additional Resource