The art of building software: Unit Testing

Tuesday, March 23, 2010

Unit Testing

I've noticed that the phrase "unit testing" means two pretty different things.  It can mean:
  1. A developer tests their own code as best they can by itself.  Others might call this "white box testing" or even "white box system testing", but my current client calls this unit testing.  Since the testing is generally not automated, there are no automated test results.  Test results must be typed in by hand, if indeed test results are even reported with this method (they are usually not).
  2. A developer writes automated unit test code, typically using a unit test framework and using mocks as needed, to test their interface and achieve maximum code coverage, with objective pass/fail results.
I'm currently working with a client that uses the definition in #1, and I've had to broaden my definition of unit testing to incorporate it.  There is so sense asking my client to use what I think is the correct definition.

I'm a great fan of the second kind of unit testing.  It gives me the confidence I need to refactor relentlessly, constantly throwing out old code and improving what's there.  That's one of the secrets to keeping productivity up over the long run.

But sometimes there is no long run.  Sometimes the projects are six week tactical exercises, after which the code is done.  In those cases, unit tests would be a waste of time.

Sometimes it was simply not possible to invest the extra time to write unit tests, because there is an initial investment in time with a payback period, and sometimes you can't afford the investment of time.

But some times those six week tactical exercises get cloned, or turned into a six month exercise.  But you never wrote unit tests from the beginning.  And the thing about unit tests is, that if your code base doesn't already have good unit test coverage, it can be quite time consuming to add after the fact.  So time consuming, that you won't do it, and you'll end up with a project that you wish had good unit test coverage, but it doesn't.

Often times, unit testing is introduced during a "re-architecting" phase, which generally seems to happen about once every five years.  That's a topic I may blog about some time - the re-architecting phase of a product life cycle.

No comments:

Post a Comment