Tests should be fast

Tests are a developer’s safety net. Whenever we perform maintenance or evolution in source code, we use the feedback from the test suite to understand whether the system is working as expected. The faster we get feedback from the test code, the better. Slower test suites force us to run the tests less often, making them less effective. Therefore, good tests are fast. There is no hard line that separates slow from fast tests. You should apply common sense.

If you are facing a slow test, consider the following:

• Using mocks or stubs to replace slower components that are part of the test
• Redesigning the production code so slower pieces of code can be tested separately from fast pieces of code
• Moving slower tests to a different test suite that you can run less often

Sometimes you cannot avoid slow tests. Think of SQL tests: they are much slower than unit tests, but there is not much you can do about it. I separate slow tests from fast ones: this way, I can run my fast tests all the time and the slow tests when I modify the production code that has a slow test tied to it. I also run the slow tests before committing my code and in continuous integration.