My XP Journey

Test Driven Design, and automated unit tests, really works - not that it is any surprise to anyone who is actually using XP. But its nice to see what is claimed in theory, personally works.

I've been building a number of low-level classes. I've built them following what I believe is the XP approach. Design by intention, build a test, run it, code it, run it again until it works. All my code is "done" - in that it is passing all the tests. (No acceptance tests yet because of our environment. An issue I know, but we are working on it). So... I'm not "running tested features" yet, but I am working stories and unit testing the code which implements them.

Yesterday another team member wrote some tests and then wrote code to pass that test, plugging it into my code. My code is very independent, using stubs, etc. It passes all the tests I've written for it. But when she tried to use it - it wasn't working.

"How can this be? It passes all the tests!"

I then looked at her data, which happens to be valid, but is more complex than the data I had tested with. It is a scenario that upon examination is totally valid, but not one I had planned for.

And this is where the beauty of XP comes in, imo.

Hmm... yeah, I hadn't planned on that, but I can see why it would be expected. How do I fix it. I'm not sure why it isn't working... but I wouldn't expect it to work seeing as how I wasn't thinking in that way. So - how to fix it. There are a number of classes and quite a few interactions, so I'm not even sure where to start. As some XP authors/writers say "I get this bad feeling in the pit of my stomach" when I start thinking about just digging into the code and trying to figure out what went wrong.

Doh... the XP light bulb goes on. WRITE A TEST FOR IT. Of course!

So I write a test, and sure enough it fails (no big surprise). OK... now what. I still don't know how to fix it, and the test fails which is what I expected... But the real reason I added the test is so that I will know when the code is actually fixed. Right. OK... now to start digging (but again, that feeling - I don't want to just dig around in the code). So, I go to the method that is failing, and I look at it. It (like most XP methods) is made up of other methods. So that the code is expressive and short. Hmm... it looks fine, but is obviously broke, so it must be one of the methods that it is calling. Well since they all have tests (YES! Good thing I followed the "test everything" rule, and didn't just test the public interfaces) - I can update each of their tests to test the new scenario. Maybe not all the data from the scenario, but given the scenario, what would their parameters look like.

Hmm... maybe its this first one. If it didn't work that would surely hose things up. Write the new test, run it. It passes. XP Bonus: Instantly I know it isn't this method. I didn't spend tons of time reading the code, thinking it all through, trying to figure out whether it should work or not. I just tried it, and it was PROVEN that it worked. Excellent.

OK... maybe this next method. Write the test. It fails. Excellent. I'm not the track now. At least this is where one problem is occurring (maybe there are others).

I look at this method (level 2, if you consider the method that is having trouble as level 1) and it makes a few calls. OK... lets just be recursive. Lets write tests for its methods. I write a test for the first method, and it fails. This method is very simple, and I go take a look. Light bulb. Of course, there are 3 conditions that this method has to process, and I only considered two of them. I've got a less-than clause, and it should really be less-than-or-equal-to. I make that change, rerun all the tests for this class, and all of a sudden I've got a "green bar". 100% of my tests are working. This tells me two things (as obvious as this might seem). 1) That I've fixed the low-level method that I just discovered was bad, and 2) that fixing that, fixed all my problems.

I commit the code, the other person pulls it, and now it works for her as well. I feel great.

• Immediate fast feedback
  
• Made "debugging" much easier - I didn't really have to debug (in the traditional sense), I just kept writing tests and following where they lead me
  
• Given the scenario that is "broken" - I can easily tell which methods are working, even though I didn't previously test them, when I write the new tests.
  
• I've proven that the code will work for this new test scenario
  
• I'm confident my code will work
  
• I'm confident I didn't break anything else (because all the other tests are still working)
  
• I feel good because I'm doing things the "right" way, and if I have another issue in the future, where I didn't think about it and test for it, I know I can easily write a few new tests and quickly find and fix the problem
  

Although we aren't "pair programming" yet, we are only 4 weeks into using the XP process, and we have things we need to learn, issues we are overcoming, etc. - the great thing is that we already see so much benefit. And to use an unscientific proof - it just "feels right". Every day as I write tests, and then write the code, and then continuing writing until the tests passes; and every night as I finish for the day, looking at all the tests I've passed, seeing how much closer we are getting to having something done (even if we take a few small steps back when something wasn't tested for and we have something that needs fixed) - I just leave work feeling so happy. One of the things I am is a "process guy". One of the people that thinks about how we should write software, not just writing software. And like I said, XP just "feels right". This is a blessing, and probably a little bit of a curse. I'm so happy the team I'm on is doing it, and I'm kind of sick feeling that all the other teams aren't. Especially when they are having problems that I know this will fix... But change comes slowly. First, my current team will prove it works, and show successes, and then we'll slowly spread it out to the other teams.

Its been a good XP day. :)