The general attitude towards testing code is usually that the quality isn't as important as that of the actual production code.
That's how I work most of the time as well. If it involves copy-paste, so be it. It's not that big a deal.
But just now I created a simple module that extends Win32::GUI to provide some introspection of a created window. I put it in a module to encapsulate the poking-in-the-internals that otherwise could be sensitive to implementation changes.
And two set of tests in the .t file was so similar that they became data driven.
How do you treat testing code? Do you keep it well factored? Do you write your own Test::Builder extensions?
The reason I use testing libraries is that I don't want to retype the same code again and again, often badly and incompletely. Test::MockObject grew out of a pattern I noticed myself using in a particular situation, for example.
Every time I've neglected to treat test code as I would regular code, I've regretted it. It's all code and the normal strategies ought to apply.
With tests, it feels like there's two kinds of duplication: repeated test setup or utility code that's more involved with the mechanics of testing, and repeated code that involves the things under test. I usually factor the former into something like Test::Utility. The latter is more problematic. Some of it may be fair game to be moved off into a MyStuff::TestUtilities. The criteria for me, though, is wether the refactoring will reduce the readability of the tests.
Tests are a form of documentation. As documentation, I'll allow more redundancy. I hate encountering code that's been refactored to the point of unreadability, only to discover that the tests, which I'd hope would shed light on what's going on, have also been brutally refactored to the point of unreadability.
