[PATCH 2/3] autodetect Perl packages
Niko Tyni
ntyni at debian.org
Mon Sep 8 17:59:14 UTC 2014
On Mon, Sep 08, 2014 at 04:04:14PM +0200, Martin Pitt wrote:
> Niko Tyni [2014-09-08 14:49 +0300]:
> > The "runtime-deps" tests do much less because it's hard to come
> > up with other generic tests there apart from "use Some::Module".
>
> So that one isn't actually supposed to run any upstream tests, but
> just check that you can load the module? This should indeed spot
> missing binary depends.
Right, that's the idea.
Possibly use.t could also do something like
use Module;
Module->new if Module->can('new');
which might exercise OO modules and their dependencies a bit deeper. Not
sure how much difference that would actually make though - I suspect
the new() methods are generally rather trivial.
We also have a syntax.t test in the 'runtime-deps' set that checks that
none of the .pm files installed choke with 'perl -c'. That might trigger
failures with some packages that only load part of their modules if a
package in Recommends: is installed. We'll see how much of a problem this
is; it should be easy to add support for a package-specific blacklist
in the test if necessary.
As future expansion, I'm thinking of using valgrind and/or some sort
of a memory leak tester in the heavy-deps tests, maybe invoking
Module->new a hundred times and checking that the memory usage
doesn't grow too badly. We've seen a few of such memory leaks over the
years. Test::Memory::Cycle also looks interesting...
But the results from the current implementation clearly have priority :)
--
Niko Tyni ntyni at debian.org
More information about the autopkgtest-devel
mailing list