Retrofitting XP-style Testing onto a Large Project?

Mr Pleonastic submits this query for your consideration: "I work for a small startup (ok, me and another guy comprise the entire development team) that has somehow managed to survive the bust, attract a number of customers, and build up about 300K lines of functionality. Up to now we've made it by being smart and conscientious hackers, but I'm increasingly embarrassed by our shortcomings in testing. I like the XP approach to making enduring, automated test suites, but most of what I read about XP focuses on obvious stuff and changing your programmer culture at the outset. Does anyone have experience with, or advice for, retrofitting it onto a fairly mature project? What do your test suites look like, anyway? The bugs I fear most are of the 'If the user does X and then Y, the result blows away our assumptions' variety, not the 'Oops! My function returned the wrong value' variety (which happens of course). How do you write good test code for the former, without spending even longer debugging the test code? Is XP just for small, new projects?"

Comments

Re:The CCCC test method (Clicky clikcky clicka cli

[Hanji]

I once did a little palm programming, and I remember the emulator had a mode where it would randomly click on various controls and enter text really quickly, as a way of stress-testing your app, testing it's ability to handle any combination of input and options without blowing up. I wonder if something like that would be useful if the world of typically much-more complex PC programs...

Step by step

[pong]

1) *Everytime* you discover a bug from now on, write a test case that exposes it. Then fix it.

2) Write new functionality test first. You are not allowed to implement new features unless you first implement a test that fails. Once in runs you are either done, or you got ahead of yourself and need to get back to writing a few more tests :-)