Jimmy’s bad experience with TDD. Was it really TDD?

Jimmy is introduced to test driven development. He has all these shiny tools that have unlimited power. Naturally, he only substitutes his current style (code-> run->point click test) with an automated test test runner. After a few days learning curve Jimmy is happy, he is cranking away on his current project and getting more done than he ever imagined. He has confidence in what he is writing because everything is green. Life is good.

Then all the sudden,some of his tests are not green but red. He reverts his code to a previous version, still red. He reboots his computer, still red. Starts debugging, only to find the data changed. The DBA’s cleaned out all the test data. Jimmy has an idea, he will use his new shiny tools to create scripts to check if the data is in the database, if not, it will populate. He spends a few days getting it just right and working with his unit test. Everything is green again, life is good. He starts coding again. Then his data population scripts start acting funny. The DBA’s changed the structure. Jimmy, while frustrated makes changes.

Then the stakeholder asks Jimmy to make some changes to the site, the changes are not small, but not too big either. But Jimmy finds that to make the changes requires more work than he is used to because he has to refactor his code, then make changes to the test, right in the middle of this process, more database changes come in. Jimmy is getting nervous because he is running out of time. Faced with the reality that is project may be late, he essentially abandons his tests, makes the changes to his code to make the stakeholder happy. He has every intention of coming back to ‘fix his tests’. He never does.

Jimmy is not the biggest fan of unit testing. He avoids it for the next few projects.

Then one day, Jimmy is assigned to a management console project. This project is painful because every little change is a pain to test. He has to run the app, log in, click through 5 different menus, fill out a form with a bunch of required fields and then submit. Development is slow and not very much fun. Jimmy know he can get around some of these problems by shifting his coding style a bit, then he can use his unit testing tools, mainly the test runner, to save some time. But when that project is over, so is the testing. He would like to do more, but bad experiences have soured his enthusiasm for what he thought was TDD. In reality Jimmy never really did TDD.
This story was written for an intro to a presentation on TDD.