Contributing autopkgtest tests to important packages
debian at kvr.at
Sun Mar 15 15:06:33 UTC 2015
I'm thinking of contributing autopkgtest tests to various important 
packages that don't have any yet. Since I will be applying the same
pattern over and over again, I'd like to ask for feedback first.
The tests I want to add are just of a very basic nature; I merely want
to increase the _breadth_ of testing. Increasing the _depth_ will be up
to the individual maintainers as they have the experience with the
package necessary to do this.
I plan to add the following tests:
If the upstream source has a testsuite that can be invoked with
`make test` or some such, use it. The -flavor suffix is
optional, and useful for eg: python2/python3 distinctions.
Motive: no explanation necessary
If the package in question is a library/module/similar, ensure
that a small test program can be compiled and run against the
installed version. Usually, such a test program can easily be
extracted from examples in the documentation.
Motive: Possibly catch errors stemming from new upstream releases,
updates, multi-archification, dependency changes, ...
If the package in question contains an executable, try to
execute it. Usually, examples on how to execute it can be
extracted from man pages.
Motive: Similar to basic-development
I welcome any suggestions with regards to how the above process could be
 This is just a vague term so far, but I guess a high popcon would be
a good indicator, or a high number of reverse dependencies
More information about the autopkgtest-devel