[Debichem-devel] test suite strategy

[Michael Banck]

Hi,

Daniel and I discussed this a while ago, but I'd like to write it down
here as well.

A lot of the debichem packages have rather expensive test suites.  For
example, I just compared apbs build and test-suite time, and it is
roughtly 2 minutes vs. 2 hours!

The following strategy looks reasonable to me:

 * Run the full test suite (maybe slightly edited to avoid really
   useless tests, if we can identify them) on major upstream versions
   and possibly also once per release cycle, if no major upstream version
   happened since.

 * Otherwise, run a reduced, quick test suite which basically only
   checks that the compiled binaries work correctly for a number of
   small test cases.

I just implemented that in the apbs version, the 1.0.0-1 upload I just
did will run the full test suite, and in subversion I've now included a
patch to add a `quicktest' Makefile target which debian/rules will run
for now.

The question is whether we want some heuristics in debian/rules to
automatically figure out which test suite to run (we'd first need a make
variable for that then, I propose 'quickcheck' and 'check' even if
some packages use 'test' etc.) and then some changelog-parsing code.

For now (lenny) we can probably get away by doing things by hand.

Comments?


Michael