I know this is iseveral days old , but we in Oz get the weekend before almost anyone else so bear with me.
When dealing with a BoM (Ball of Mud), there is a fundamental collision of two concerns here. 1. To test the code, you need to change it. 2. Before changing the code, you should test it. How do we resolve these two opposites ? We change as little as possible. A lot of my more recent thoughts about testing and development have come from a wonderful book <plug mode='on'>Working Effectively with Legacy Code by Michael Feathers"</plug> The most memorable line from that book (that I've read so far - I'm still in the first 25%) can be paraphrased - 'Whatever the difficulties with a BoM codebase , never let "best" be the enemy of "better"' I would posit the _none_ of use have _perfectly_ clean codebases we deal with from day to day - they occupy a space from 'almost perfect' to 'abandon all hope'. I would also posit that no matter how bad a codebase, there is _always_ sonething you can do without causing damage - in the 800 line subroutine, take a chunk, place it in a function in a namespace, and test that in isolation. Take another chunk, repeat till you have a 500 line subroutine with some semi-meaningful calls to nicely tested functions. And so on. Enough preaching - the oven says my pies are ready!! Leif -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, 12 January 2007 6:49 PM To: perl-qa@perl.org Subject: RE: Test::Builder feature request --- [EMAIL PROTECTED] wrote: > I think code under test that has "if I'm under test" statements is > intrinsically weak. You want to test "what it does", not "what it does > when under test". Changing the code for testing means your not really > testing it , your testing a variation of it. I completely agree. In a perfect world, that's extremely sensible. But I wonder, has no one here ever sat down to the daunting task of taking a Ball of Mud and trying to test it? So you want to clean up that Ball, what do you do? Before refactoring, write tests to verify all behavior, including bugs. That's pretty much testing dogma and it's dogma I generally subscribe to. That's where the problem comes in. You're looking at an 800 line subroutine, no strict, no warnings, and scattered hither and yon throughout that subroutine are Bad Things to have happen while testing. Not everything is that easy to override or mock. So that leaves on in a dilemma. Not only are the tests excruciatingly difficult to write, but the mere act of running them is dangerous. Customers potentially get rebilled, accounts get deleted, support tickets get sent out, and so on. So I guess that while everyone else has the luxury of working with systems which are clean enough that it's not too expensive to work around issues like this, I'll shelve this suggestion and go back to the real world and continue trying to clean up this legacy code. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/ -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.410 / Virus Database: 268.16.10/625 - Release Date: 13/01/2007 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.410 / Virus Database: 268.16.10/625 - Release Date: 13/01/2007 ********************************************************************** IMPORTANT The contents of this e-mail and its attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you received this e-mail in error, please notify the HPA Postmaster, [EMAIL PROTECTED], then delete the e-mail. This footnote also confirms that this e-mail message has been swept for the presence of computer viruses by Ironport. Before opening or using any attachments, check them for viruses and defects. Our liability is limited to resupplying any affected attachments. HPA collects personal information to provide and market our services. For more information about use, disclosure and access see our Privacy Policy at www.hpa.com.au **********************************************************************
