On Monday 24 January 2011, Iustin Pop wrote: > This is a very good idea, but I think it could be taken two steps > further. These are just some ideas I have but did not explore in > depth, so take them with a grain of salt. > > 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. > > Of course, these would be useful only for some classes of packages, > but for those they would be of much help. I have something like > this in one package of mine, and it gives me a lot of confidence > while doing packaging changes.
FWIW, Ubuntu has a regression test suite: https://code.launchpad.net/~ubuntu-bugcontrol/qa-regression- testing/master I didn't have a chance to look at it, yet, though. Cheers, Stefan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101242132.26170...@sfritsch.de
