Selling Agile (testing)

(archived from my old blog from my pre-MS days)

It's amazing.  The battle for agility is far from won.  Folks are still not writing unit tests.  Some folks don't even know what unit tests are, or have a badly mangled definition of them.  I'm not only finding this as a consultant at client sites, but among some of my own colleagues as well.  A developer asked me last week, "What is this agile thing?"  I seriously thought that by now people would have at least a basic understanding of what it is.  But alas, it not currently so.  This isn't to castigate anyone.  I'm more than happy to help folks out with "this agile thing".

So what is Agile?  I point you towards the Agile Software Development Manifesto, and some further explanation, and the "original wiki" houses a great deal of info on agile.  There is much info from people more eloquent than I.  Those who don't know what "agile" is usually know what "Google" is.  Use your search engine of choice and explore.  But back to testing...

Test your doggone code, people!

Why? Because I like to sleep at night.  That means that not only do I have to test my own code, but if I depend on your code, you better be testing yours.  What?  I don't take your word that you've done an excellent job as a developer?  Frankly, no.  I don't trust me, and IMHO I consider myself somewhat more than competent as a developer.  Therefore, if I don't trust myself, why in the world should I trust you?  I read somewhere (I think it was in Ron Jeffries' book, Extreme Programming Adventures in C#) that without testing, the average developer could only write about five lines of code before introducing a bug.  My own folly has born this out in the past.

So if you don't test your code and I'm left to work with it, then I have to find the seams within your code and crack it open to wedge in support for testing, as found in Working Effectively with Legacy Code, by Michael Feathers.

It's all about confidence

Before I embraced the agile lifestyle, I never really knew if my code was doing what I thought it was supposed to do.  I hoped and prayed that it would.  And really, at that point, prayer was my only option, because I didn't know whether the testers (when we had them) were doing an adequate job.  What did we do when we didn't have testers? Well, testing turned out to be the weeks and months after going live on a production environment - not the best time to do your initial testing.  Demos and integration testing were high stress times for me.  I didn't even want to be around when they happened.  I don't enjoy getting yelled at (or looked down upon as incompetent) any more than the next person.

So I took the time to learn about unit testing.  NUnit was the only thing available to me as a .NET developer at the time and it seemed to work well.  Over the years I started with writing unit test - bad unit tests to be sure, but tests nonetheless.  I recently had someone tell me that the code that they had written was too difficult to test and thus it was better to not have any tests at all.  I fail to see the logic in that (besides the fact that there are really very few situations that cannot be adequately unit tested if designed correctly in the first place).  Bad unit tests are SOOOOO.... much better than no unit tests.  Even if your unit tests are brittle and return false-positive results, at the very least you are thinking further about how your code will be utilized.  It could be argued that you can have a false sense of security with badly written tests, and while that my be true, what, if not a false sense of security, is someone operating under when they have NO tests?

Now, with proper testing in place, I have no problem ripping out huge sections of code and replacing them when requirements change.  Why?  With the press of a key I can run all my tests and confirm that yes, all is well.  That for which I am responsible... just works.

In my organization we're going to start trying to bring all the developers up a notch or two.  If you write tests then that's the beginning - the very beginning.  There is so much more to understand about improving the quality of code.  But testing is the very first thing.  If you're not testing your own code - just stop.  Turn around, and take some responsibility for quality without cowering behind some large object when your code goes live to the public.