Hi! Some days ago I committed the beginnings of a C unit test suite (I was not really satisfied with any of the existing frameworks), and will be working on making it more thorough, by continuing to refactor the code and making it unit testable.
I've also created a new (private) repo for dpkg functional testing, including mostly packages to be built directly with «dpkg-deb -b». <http://git.hadrons.org/?p=debian/dpkg/pkg-tests.git> This is work in progress, to experiment with possible frameworks and mainly to start collecting test cases. Also due to the requisites of testing installation and removal of packages (need for root and ideally a debootstrapped chroot, at least), which are better handled at release time instead of build time, I think it's better off in a separate repo for now. The functional tests that do not need package installation/removal could be moved to the dpkg.git repo, though. For these kind of test I've been thinking about using autotest (autom4te) as it's well integrated with automake, and if needed to write a small support shell library to be used in combination with automake test functionality to avoid increasing significantly the needed build dependencies. Something that would make it easier to write and maintain the pkg test cases would be to have all the DEBIAN contents in a single control file (there's an example in the repo), a la equivs or spec-like form. Such tool would also be a nice way to "merge back" equivs into dpkg. regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org