On Mon, Jan 24, 2011 at 12:19:32AM +0100, Iustin Pop wrote: > First, tests run during a package build are good, but they do not > ensure, for example, that the package as installed is working OK. I've > been thinking that (also) providing tests to be run after the package is > installed (and not on the build results) would be most useful in > ensuring that both the build process and the packaging is correct. > > Second, README.test are designed for human consumption, whereas a > standardisation of how to invoke the tests would allow for much more > automation. E.g. piuparts would not only be able to test that the > install succeeds, but the automated tests also work. Exactly. In the NeuroDebian team we started playing around with more comprehensive testing -- both regarding single packages, but also integration tests involving multiple packages. We started composing a SPEC for a testing framework, but we haven't gotten very far, yet. What we have is here http://neuro.debian.net/proj_debtest.html and here http://git.debian.org/?p=pkg-exppsy/neurodebian.git;a=blob_plain;f=sandbox/proposal_regressiontestframwork.moin If somebody is interested in working on this topic, we'd be glad to join forces. Originally, we wanted to develop the SPEC a little further, but since the topic came up, I figured it might be better to add these pointers now. Michael -- Michael Hanke http://mih.voxindeserto.de
Attachment:
signature.asc
Description: Digital signature