Contributing autopkgtest tests to important packages

[Christian Kastner]

Hi,

I'm thinking of contributing autopkgtest tests to various important [1]
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:

  Test: upstream-testsuite{-flavor}
        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
  Example: [2]

  Test: basic-development{-flavor}
        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, ...
  Example: [3]

  Test: basic-invocation
        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
  Example: [4]

I welcome any suggestions with regards to how the above process could be
improved.

Regards,
Christian


[1] 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

[2] https://sources.debian.net/src/python-cachetools/1.0.0-1/debian/tests/

[3]
https://sources.debian.net/src/libfann/2.1.0~beta+dfsg-1/debian/tests/build/

[4]
https://sources.debian.net/src/liblinear/1.8+dfsg-4/debian/tests/executables/