Michael Hanke wrote: > On Mon, Jan 24, 2011 at 12:19:32AM +0100, Iustin Pop wrote: >> 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
Thanks for starting this project! I hope a lot of progress is made so that it can be used for Wheezy. This topic is something I've been slowly working but haven't had much time. Other ideas: * http://bugs.debian.org/512265 * Something I wrote the other day (related to the d-d-a email): > A long term plan could be to push the creation of a framework so that it > is easy to test things such as webapps (which may require an httpd) and > other packages that are not very to setup (e.g. by providing a script that > creates a basic virtual machine, installs the needed stuff and then > control is handed over to the package-specific bits). > > Automated testing is something that we really ought to push. And there's also the possibility of re-using the same test framework to allow automated fuzzing (and easier fuzzing using custom environment, etc.) Somehow related to DACA too. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- 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/ihipds$t3k$1...@dough.gmane.org
