次の方法で共有

Unit Test Rules

  • [アーティクル]

Michael Feathers has posted a set of Unit Tests Rules https://www.artima.com/weblogs/viewpost.jsp?thread=126923

 

he said:

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.

 

I understand his motivations to write this, however I think his position is very aggressive. Frankly, I have learned UnitTests reading tests from other people, and I've always seen some kind of dependencies with the Filesystem and sometimes a Database, and I don't think this makes these tests less Unit.

 

I would like to reconsider each of first three points:

 

It talks to the database.

  • use different db for unit and integration testing
  • the database can be created from scratch easily
  • tests uses the smallest amount of data they could
  • unit tests always execute though a local db instance

 

It communicates across the network

I always avoid to depend in another machine, so if you need to use the network always use localhost, and like the db, you must be able to setup the server side easily in your dev/build box.

 

It touches the file system

I completely disagree this one, it's like if you said "it touches the memory". I don't like to depend on predefined paths and I always try to put my testfiles as resources of my test library, however there are too many situations where using the FS make things easier.

 

Finally I agree with the last two sentences…

Comments

  • Anonymous
    September 21, 2005
    Hmm... if I can't talk to the DB how do I unit test a data access layer or anything that sits on top of one? Create an entire mock implementation of a database provider just so I can unit test? Methinks not.

    I agree with your position and that's exactly what we do here. Not only that but we use transactions to ensure that unit tests do not leave lasting effects on the DB.

    Same thing goes for network and file system. I think the key to unit tests is just to make sure that you don't leave any risidual artifacts between tests that could affect future tests in any way.

    Just my 2¢,
    Drew