Retrofitting XP-style Testing onto a Large Project?

Posted by Cliff on Friday September 5, 2003 @09:22AM from the XP-also-means-eXtreme-Programming dept.

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?"

2 of 49 comments (clear)

Min score:

Reason:

Sort:

Somebody had to say it by Sklivvz · 2003-09-05 09:32 · Score: 5, Funny

Win XP style testing? So, what's so hard? Release an alpha version and call it RC, and let users do the testing...
</wintroll>

--
My Stack Overflow user
Re:Retrofitting is Hard! Refocusing is Easier! by Anonymous Coward · 2003-09-05 10:57 · Score: 1, Funny

Hold on dude! You are not a programmer, so you shouldn't give advice on programming.

Your resume clearly indicates that you are just a Perl hacker. As everyone knows, Perl is not a real programming language.

Come back when you know a real programming language.

Thank you and good night.