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!
.NET TDD Roundup #1
This is .NET TDD roundup #1.
The .NET TDD roundup aggregates information of interest to .NET developers using TDD/BDD. If you have something interesting you have done or have run across, please send me the URL with a brief description via the contact link on my blog.
Read More »
Technorati Tags TDD