Unit testing and TDD
Back in March, I wrote a column entitled “Unit
Testing and Test-First Development“.
I’ve been playing around with unit testing a bit more since then, and have a few tentative
conclusions.
-
Unit testing is, overall, a “Good
Thing“ -
Unit testing works well for class libraries, especially ones that act fairly statically.
If you create one of these, you should be writing unit tests -
Unit testing is hard with graphical applications and/or dynamic applications. I have
an app that I’m writing that uses multiple threads, fires events asynchronously, and
is peer to peer. There aren’t any unit tests for that section yet. -
Unit testing is great for tricky code that you wrote but weren’t sure that it really
worked. I updated my Regex Workbench a while back,
and in the process wrote unit tests for all the code that I have that interprets regular
expressions to english. I found one feature I hadn’t implemented, and two that were
implemented incorrectly. I’m now much more confident that it works.
I’e also been playing with Test-driven development. I’m not sure about it yet, though
it is true that if you write the tests up front, you’re much more likely to write
them.
It is possible to write unit tests for the more complex examples. I’ve been working for a few months on a system that uses multithreading, and connects multiple machines by remoting. The unit tests for dealing with the remoting aspects and the threading were much harder to write. But the amount of thought that went into writing them had a very beneficial effect on the code.
I’ve found that every time I come to write a piece of code in a scenario that I’ve never written a unit test for before, my initial gut reaction is "How on earth would I test that? Maybe I won’t bother…" But with perseverance it’s surprising how much you can test for if you get creative.
The thing that amazes me is how hard some resist using unit tests. Some are more than willing to spend hours testing, and retesting code, but don’t want to lift a finger to write a unit test. They "don’t see the benefit". When I show them how fast my tests run and reinforce to them that nearly all of my testing logic is captured for all time and is super easy to run after "small" changes. They go glass eyed and blow me off.
My last project had 4 bugs reported from our test group. Unit testing made that possible because it was so much easier to retest *all* my code after I made underlying changes. Without unit testing it would have been much higher.
I don’t plan on going back.
Ian,
Are you testing directly to the remote system, or are you using mock objects?
I like unit tests and I’ve seen them work to great benefit before, but I hadn’t really tried TDD. I really meant to on this new project, but I convinced myself I didn’t have enough time. Then after a series of emberassing bugs I hunkered down and wrote tests for my existing stuff (did some refactorign to make that possible) and did TDD on the next objects I wrote.
The fact that I didn’t have to start up my ASP.NET app in the debugger to test new functionality was time saving enough, but the fact that there were almost no bugs more than justified this approach. I also really like seeing things work immediately. I don’t know why everyone doesn’t do this, but I also have run into developers who flatly refuse to do so. Gluttons for punishment, maybe?
[http://itpeixun.51.net/][http://aissl.51.net/][http://kukuxz003.freewebpage.org/][http://kukuxz001.51.net/][http://kukuxz003.51.net/][http://kukuxz005.51.net/][http://kukuxz002.51.net/][http://kukuxz004.freewebpage.org/][http://kukuxz007.51.net/][http://kukuxz001.freewebpage.org/][http://kukuxz006.51.net/][http://kukuxz002.freewebpage.org/][http://kukuxz004.51.net/][http://kukuxz008.51.net/][http://kukuxz009.51.net/][http://kukuxz005.freewebpage.org/][http://kukuxz006.freewebpage.org/][http://kukuxz007.freewebpage.org/][http://kukuxz009.freewebpage.org/]