Lots of developers and software companies make use of unit tests. Either to just ensure that new code does not break existing code, or because they are using test driven design. One potential problem with unit tests is that as time goes on, the testing suite can become so bloated that developers stop running the unit tests against their code. The test still get run on some sort of regular, or occasional basis, but the tests don't get run every time a developer checks in code (as they should).

One reason that this happens is that often when people are writing unit tests, they aren't. Instead they are writing functional test. While functional tests are absolutely needed and just as useful as unit tests, they should be kept separate so that the "real" unit tests can be run quickly.

The problem that most people make is that unit tests are really intended to test just one "unit" of code. They are not intended to test interactions between objects or different layers in the code base. Those are functional tests. Again, functional tests are absolutely needed. You just want to make sure you separate them so that unit tests can be run quickly.

When you are writing your unit tests, here are some questions you can ask yourself to make sure you are writing a unit test and not a functional test. If you answer "yes" to any of these, you are not in fact writing a unit test.

1) Does the test require communication with the database or any other outside resource like a network? External resources like the database should be mocked out since you are trying to test the thing that talks to the database; the process of communication is functional.

2) Does the test touch the file system? Again, this is an outside resource, it should be mocked.

3) Can test not be run when other test are running? Unit tests should be free of state and should be able to run anytime independent of other tests that are being run.

4) Does the environment, or configuration files, need to be altered to run the test?