Unit Test Your Fixtures


As I was writing the CommandLineFixture for the SmcRemote unit tests, I fell into a trap. I wrote a little bit of the acceptance test, and then made it pass by writing a little bit of the CommandLineFixture. This felt so much like TestDrivenDevelopment that I didn't notice I wasn't writing unit tests. The FIT table felt like my unit tests.

At first, things went along swimingly. Each new step caused both the FIT table and the CommandLineFixture to evolve. However, after several hours the purpose of the FIT table started to assert itself. That table was being written to test something specific in the SMCRemoteService program. It was not being written as a unit test for CommandLineFixture. More and more code was written in CommandLineFixture without the benefit of good testing. My edit/compile/test cycles started to stretch out longer and longer, and I became quite nervous.

Unfortunately I let this go on a bit too long. There are not enough unit tests for CommandLineFixture. Eventually I realized what I was doing and started writing unit tests, but it was already too late for much of the code. It had not been written to be unit testable, and it's structure would not easily allow unit tests to be inserted after the fact.

Lesson: Don't be fooled into thinking that FIT table is a unit test for a Fixture. Write specific unit tests for your fixtures.

 

Last edited November 15, 2002
Return to WelcomeVisitors