Re: package testing, autopkgtest, and all that
On Wed, 02 Feb 2011 at 14:15:07 +0000, Ian Jackson wrote:
> So if the tests were in binary packages, often we'd have to construct
> a weird binary package which contained all or part of the built source
> tree. This would be very ugly and also bulky.
FWIW, Maemo does this, and it's a pain to deal with in practice. Basically
nobody writes upstream tests like this, leading to a lot of strange goo in
debian/rules:
http://gitorious.org/gnome-essentials/dbus-glib/blobs/maemo/debian/rules
I think Ian's right, this approach should be avoided.
> This is probably going to be
> much harder than simply arranging for the tests to test the installed
> rather than built copy (if they don't already).
For those familiar with Automake or the GNU coding standards, this is the
distinction between "make check" (take the uninstalled copy I just compiled,
and test it), and "make installcheck" (test the installed version of this
package). Automake's "make distcheck" also runs installcheck on the
just-installed binaries, if implemented.
I get the impression that implementations of installcheck are also quite rare,
but telepathy-mission-control-5 is one example of a package that has it.
It runs a subset of the "make check" tests on the installed binary.
(It's a subset because some of the Mission Control tests require extra hooks
in the binary, to manipulate its internal state directly - the "make check"
tests run on a modified binary with extra D-Bus interfaces to do that, but the
tests relying on this functionality are skipped in "make installcheck" because
they wouldn't work.)
Simon
Reply to: