Re: Philosophical question about testing

[Monkomatic]

One of the few quirks with perl is that:

The 20 line code you wrote 4 weeks ago.

Becomes a 15 line code 2 weeks later.

Then 1 week later you discover how to do it in 2 lines.

And then someone (usually on this very forum) points out that it is possible in 1.

This is why modules and subs arent talked about much

So I wouldn't really stress the Philosophical side of modules. Do it to help understand how to share your code with the community when you have code you wish to share. (CPAN)

[dsheroh]

While your given "quirk" is true (TIMTOWTDI and all), I draw exactly the opposite conclusion from it: When there are many ways to do something, the philosophical side helps to decide which is the appropriate way in any given situation.

More relevantly to the original question, being likely to change the implementation of a method over the lifetime of the code means that it's less of an issue if your testing code mirrors the (original) implementation, since it will still assure you that the method produces the same results after its implementation is changed. (But, that said, I agree with earlier responses that this particular case sounds like one in which breaking the code down further into finer-grained methods and testing those smaller pieces independently is the way to go.)

[doom]

This is why modules and subs arent talked about much

Modules and subs are talked about all the time by perl programmers who have half a clue about what they're doing.

If you push a block of code off into a sub inside a module, among other things you'll discover that it's much easier to write tests for it, and once you've got tests for it, it's much easier to re-write it as you describe (though reducing line count is hardly ever the first priority).