Developers write their tests usually with a unit test framework. Often those tests are slow and unreadable. Almost always the tests communicate with a database, a file system, a web service or other external resources. Developers stop executing the tests regularly and further they stop writing tests entirely, because “unit tests” are so slow and hard to maintain.
Michael Feathers has already summarized the criteria for unit tests in September 2005:
“A test is not a unit test if:
- It talks to the database
- It communicates across the network
- It touches the file system
- It can’t run at the same time as any of your other unit tests
- You have to do special things to your environment (such as editing config files) to run it.
Tests that do these things aren’t bad. Often they are worth writing, and they can be written in a unit test harness. However, it is important to be able to separate them from true unit tests so that we can keep a set of tests that we can run fast whenever we make our changes.”
Developers often even do not write unit tests! They are writing integration tests instead. Sometimes it takes more than knowing the test attributes of the used unit test framework to write real unit tests!
One Comment
Thank you Andreas!
Assert.That(this, Is.TheTruth()); // ;-)))