Tests have a better memory than you do

My past several blog entries have been about testing, more precisely about unit testing or test-driven development. I suppose I should talk about how I got started on all of this.

Up until few years ago, I developed code in a "conventional" style, that is, without unit tests. I kept hearing about unit testing and test-driven development but I didn't know what to make of it. I read a couple articles and it seemed sorta weird, but I didn't really catch on. But, as my experience shows, you can't catch on to something just by reading about it. You have to do something and experience it.

So, I decided that when I next had a couple spare hours free (naturally, this was a major source of delay) I assigned myself a simple programming task. The actual task isn't relevant, but it was simple enough that I could implement something of interesting complexity within a few minutes and then add features incrementally.

But I did eventually get the time to do this. I downloaded JUnit from junit.org and followed the procedure of writing the test for the code before writing the actual code. I felt really stupid at first. I couldn't even compile the test, since I hadn't written any code yet, not even a stub! But I kept going: I added the code, and then the test passed. I added another test (which failed, of course) and then I added the code to make the test pass. And so forth. I even started taking shortcuts by writing the test and the code at the same time. It's not strictly by the book, but what-the-heck. After a while, I had a couple hundred lines of code and a dozen or so unit tests. Things were going pretty smoothly.

But then something really interesting happened. I had implemented features A, B, C, and D and their corresponding unit tests. I added a test for feature E and then code to implement feature E. I ran the tests, and the test for the new feature E passed. But the test for feature B failed!

This came as quite a surprise to me. After programming for only a couple hours, and with only a couple hundred lines of code, my unit tests knew more about my code than I did. When I implemented feature E, I thought it would work -- and it did -- but I also thought that it wouldn't break anything else. I was wrong. It just goes to show that your unit tests have a better memory than you do.

I've been test infected ever since.

Comments:

hey s'mark - i've loved junit for awhile now but felt a bit constrained when working with several objects which have various dependencies on one another and such, yet writing a singular unit test in such an env, which all apps hit in time as they grow/scale, has been problematic ... well, for me. recently i've been exposed to jmock(.org) and xmlunit(.sourceforge.net) ... both of which sit nicely upon junit. w/ jmock, one can stub in the dependency "behaviour" while focusing on the test unit. xmlunit let's one check xml output for equality ignoring whitespace, attribute and element ordering, etc. junit + jmock + xmlunit = powerful mojo! best, - james

Posted by james todd on August 17, 2006 at 03:31 PM PDT #

Hi James, good to hear from you. Yes, satisfying a unit's dependencies when creating unit tests seems to be quite an art that I haven't totally gotten a handle on, but over time I've gotten better. So far most of my unit testing work is taking "legacy code" and refactoring it to bring it under test. Effectively what I've done is created my own Mocks by hand. I'll take a look at jmock and see if it can help this process. Thanks! --smarks

Posted by Stuart Marks on August 18, 2006 at 02:58 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

user12610707

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today