--- [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/
