I posted two articles on unit testing on my previous web site. On 2005.09, Michael Feathers posted an excellent article: A Set of Unit Testing Rules, which attracted quite big interests among developers.

I agree with Michael totally (almost, see below). I think ‘unit test’ probably is the most widely mis-used / mis-interpreted term in software industry. There is urgent need to clarify it.

Here is summary of my understanding of Michael’s unit test rules and some points I made in my posts.

A test is NOT a unit test if:

It talks to the database
99% Agree. Only exception is using in-memory databases. On last project, we used HSQLDB unit testing DAO calsses based on Hibernate and iBatis frameworks.

It communicates across the network
100% agree. This is a typical integration test.

It touches the file system
95% agree. For certain scenarios (for example, complex XML transformations), creating test data generator might not worth the effort, embedding big XML strings in source code making test class bulky and less readable. Whenever you can, try to avoid loading test data from file systems.

It can’t run at the same time as any of your other unit tests
Yes! This is one key point I found many books on testing missed it. Especially for .NET projects, taking this into consideration when setup the directory structure.

You have to do special things to your environment (such as editing config files) to run it.
100% agree. This may not be big issue in Java land now, but

Here are some extra points from my experience:

• It executes slowly (>0.1 seconds). Slow tests tend to make developers running all tests less frequently.
• It is hard to write. Simply developers will not write tests if it is not easy to do it. ‘Simple design’ (See Jon Tirsen’s post, it is very very hard) and using mock objects will simpify the task dramatically.
• It generates inconsistent test results. The test result shall always be consistent whether it is run individually or as a part of a suite.