Re: Automated testing - design and interfaces
Bill Allombert writes ("Re: Automated testing - design and interfaces"):
> Currently Debian packages are tested through a lot of channel:
> [stuff]
Right.
> Debian is an organisation which can afford a lot of decentralisation,
> but where centralisation is very expensive [...]
Right.
> Doing the checks in debian/rules is not perfect, but it happens before
> the package is uploaded, is performed for all architecture and more
> importantly is done with the current infrastructure.
A big problem is that doing the checks in debian/rules will fail to
spot many obvious packaging mistakes.
> Going toward a centralised testing facility [...]
This is one of the things that Ubuntu will be using it for. But one
of the things that I expect Debian to use the same facilities for is
to allow a developer to do a test of the package they're about to
upload, _after building and installing it_.
This might, just as one example, help get rid of a lot of the `NMU
broke it totally'. And, of course, there have been occasions when the
maintainer didn't really test the package after installing it because
it was too much trouble. If it can be standardised and automated, and
if a way can be found for Ubuntu to share tests with Debian, then
everyone wins.
> If Ubuntu want to improve the testing coverage, you could start by
> submitting patches to packages that don't run test-suite in
> debian/rules. That would profit both Debian and Ubuntu and there are
> lot of work to do there.
Running the upstream test suite in debian/rules usually isn't the
answer to packaging mistakes, library mismanglements, and the like.
Ian.
Reply to: