Perl Monk, Perl Meditation | |
PerlMonks |
Re^2: Developing a module, how do you do it ?by tobyink (Canon) |
on Feb 29, 2012 at 12:44 UTC ( [id://956917]=note: print w/replies, xml ) | Need Help?? |
Agreed -- if you're working on a bunch of tightly coupled modules, they should live in the same source tree (thus the same "lib" directory), so they all get tested, published, upgraded as a clan. If your modules are loosely coupled enough to live in their own source trees, then a good test suite should prevent regressions in one affecting another. The exception to the above is where one module uses a feature of another which has no test cases. So make sure your test suite is comprehensive enough to cover everything. Case in point: I recently contributed a feature to XML::LibXML which used overloading on XML::LibXML::Element. However, once 1.91 (and 1.92, which was a quick bug fix for Perl 5.8). This broke the ability to do: if ($element1 == $element2) { ... }Why? Because if you overload one operator, you need to overload every other operator you plan on using. This bug was fixed very quickly in XML::LibXML 1.93, but how did a release with this bug actually get published? Simple: the ability to check equality between XML elements was never checked in the test suite, so even with this regression the full test suite was passing. The moral of this story is: make sure that your test suite covers every public interface of your module that its users might be expected to use.
In Section
Seekers of Perl Wisdom
|
|