Five Ironies of Unit Testing

great post, all so true! I don't really see the last point so much, in my experience developers who don't write tests don't even look for any existing tests when they come to maintaining existing code, much less bother running them after they've made any changes ;)

After writing unit tests on a recent project, I can tell you that all 5 points here are circumstantial, and not exclusive to unit tests, and one point (number 2) is just dead wrong. Unit tests will not save you time in the sense that they will create a scenario in which your code takes less time to write. Think about it for a minute. For those that write amazing code, you still have a test to write. So you have code, and you have a test. Now eliminate the test, and write amazing code... you just saved yourself time. The reality is that any exercise that teaches you how to think about code before you write it is a good exercise. You simply need to get to a point where you write amazing code -- a test is just one way to do that. If I do a UML diagram, or any class hierarchy diagram that forces me to actual think about the implementation, then that is going to be beneficial.

I keep hearing about Unit Testing and I would really like to see how it actually improves the testing of the software. But consider the project that I work right now on, I can't even figure out how to write a unit test. The project works on a framework of state machine stacks and an event model. This project has functions called from a whole lot of different state machines and even stacks. Writing unit tests is easy before the implementation but seems like a nightmare after it.

Not so sure about point #1. "The devs who would most benefit from unit tests are the devs who are least likely to write them - and vice versa. The star devs, who would write the code correctly to begin with, are also the ones most open to unit testing."

The people who benefit most from unit tests are those who come along later and inherit responsibility for maintaining the code base. (Maybe too fine a point.)

Also, writing code "correctly" means writing it in a test-first fashion. No one can write code "correctly" off the cuff, no matter how talented or experienced. Therefore, it is redundant to describe "unit tests" and "writing code correctly" because the two are part of the same process.

Brian,

Unit tests (especially in the context of TDD) do save development time. You're thinking of just the "typing time." If we consider the end-to-end time from the moment development starts until the code is correct and ready for deployment, then unit tests (and especially TDD) result in a net savings of time, since they eliminate nearly all the time that would have been spent in debugging using traditional methods.

With contemporary approaches to development, if you haven't tested the code, you haven't really "developed" the code at all. You haven't finished your work yet. So, it's meaningless to subtract testing time or debugging time from development time.

Kevin,

You might want to investigate the concept of "test isolation." You can find a lot of references by doing an internet search. If you can come up with a practical way to apply this concept in your environment, it might help you with some of the challenges of unit testing. There are no magic bullets, of course.

In most cases when people tell me they can't think of a way to write unit tests for their code, it turns out to be at least partially because they aren't accustomed to thinking about how to isolate parts of the code. Just food for thought.

@Brian - "(number 2) is just dead wrong. Unit tests will not save you time in the sense that they will create a scenario in which your code takes less time to write."

While I agree there's always exceptions, I disagree that this is "dead wrong". Especially for non-trivial, in-memory business logic, unit tests can save a ton of development time because they let you jump directly to the problem area and test it. Say a web developer has code embedded in a messy aspx page, and say they need to test 10 different scenarios. Without unit tests, they essentially need to run the app under all the scenarios (and it takes non-trivial time to get the app ready for each scenario). If they refactored that code out to a method that can be unit-tested, they can quickly write the 10 different tests and verify them. Typing the code isn't what takes time; rather it's thinking and verifying the code. The divide-and-conquer nature of unit tests lets you drastically reduce the verify time, and therefore it overall saves time during development alone, let alone integration testing or maintenance.

There is more than that. Number 6. should be:

• 6) Unit tests often time provide a false sense of security.

I could think even of no. 7, too:

• 7) Unit tests can be abused so that component testing or even integration testing goes into them.

@Brian - "You simply need to get to a point where you write amazing code -- a test is just one way to do that. If I do a UML diagram, or any class hierarchy diagram that forces me to actual think about the implementation, then that is going to be beneficial."

I think once you get to the point where you *think* you are writing amazing code, it can be a dangerous place as it implies you believe there can't possibly be bugs in your code (it's amazing, how could it contain a bug?!). So there are gotchas here.

It's also about thinking now just about now, but about the future. You could write a UML diagram etc. but you can't execute a diagram as part of a continuous integration environment - it can't tell you when someone (or even you) changes the code x weeks/months down the line and breaks it. This is one of the areas of value that unit testing adds over diagrams. Unit tests provide increased confidence in refactoring.

Of course, you can't afford to be complacent if you do have unit tests either!