• Created by Unknown User (evers_m), last modified on 29-01-2010

By Michael Feathers; link: http://www.artima.com/weblogs/viewpost.jsp?thread=126923

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.



  • No labels

1 Comment

  1. Unknown User (don)

    Looks like an idea to use Categories was not that bad at all. However dependencies between test projects still remain as an issue.

    Additional points to the above list, more oriented on our solution:

    • Projects containing unit tests can reference only projects which they test
    • All test not satisfying the above requirements are integration tests
    • Integration tests can be:
      • DataAccess tests - integration tests using any file reading / writing, storing data in the database.
      • WindowsForms tests - tests showing controls
      • Performance - tests checking timing (however some of them can still be called unit tests ...)
      • Requirements tests - FitNesse or any other BDD tool
    • Integration tests may reference other projects, e.g. test testing writing and reading project containing 2d grid may reference DelftTools, DataAccess and SharpMap assemblies.
    • Unit test projects may still contain integration tests, if they don't require any other references except projects being tested