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!