Re: Developing a module, how do you do it ?

in reply to Developing a module, how do you do it ?

I'm wondering if you're using regression testing. The fact that you need to install stuff regularly suggests that perhaps you're doing that to manually test each small change. My workflow is to make changes to tests and code in parallel and regularly run prove -l or make test (or dzil test for code that I package with Dist::Zilla). When I'm happy that I have the required features working, then I build a package and install it. If you're not familiar with Perl's regression testing tools, this document might help.

Also I'm sure you realise this, but just in case you don't ... a distribution can contain more than one module. So you might use Module::Starter to generate a skeleton distribution including a .pm file under the lib directory. But you can put other (related) modules in the same lib directory so when you develop your code and your tests, the family of modules are developed together. Then a make install will install them all. To put it another way: if you want to make 5 related modules you don't need to run Module::Starter 5 times.

You might also get some mileage out of setting the PERL5LIB environment variable to point to the lib directory containing the code you're currently working on. Then when you run a script it will use the development version of anything it finds in that directory and the installed version of everything else.

Comment on Re: Developing a module, how do you do it ? Select or Download Code

Replies are listed 'Best First'.
Re^2: Developing a module, how do you do it ? by tobyink (Canon) on Feb 29, 2012 at 12:44 UTC
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.	[reply] [d/l]

Replies are listed 'Best First'.

Re^2: Developing a module, how do you do it ?
by tobyink (Canon) on Feb 29, 2012 at 12:44 UTC

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.

[reply]
[d/l]

In Section Seekers of Perl Wisdom