Hi, On Thu, Oct 05, 2006 at 01:52:29PM +0200, Raphael Hertzog wrote: > [...] > I bet for lack of time... all the dpkg developers that I know are > reasonable and wouldn't want to throw away the work of someone else if he > has taken care to ask for regular review of his work.
OK, thanks for your reply.
> Ian Jackson said he's ready to give advice on dpkg developement in
> general. Furthermore it did some groundwork on a testing framework for
> Ubuntu (it was a package testing framework), so I'm sure that he could
> review your work in that area.
OK, I would love to have some comments/criticism from Ian (and anybody
else, for that matter).
> Just go ahead!
Right now there are two proposals. If people want to review them and make
some comments, but lack the time to review both, _please_ ignore the first
proposal (well, even if you have lots of free time: begin with the _second_
one and only review the first if you don't like the second).
Just to try to speed things up, I have prepared a kind of executive
summary. But before that, PLEASE TAKE INTO ACCOUNT: *testing is way easier
than it seems*, it you don't understand terms or want to help but think it's
too hard, please don't think so, and ask whatever you want. We could even
arrange an IRC meeting to make a demo, explain the framework or the underlying
ideas, or just to discuss the design of the whole thing.
------------------------------------- 8< -------------------------------------
Dpkg Testing Framework Proposals Executive Summary
==================================================
Both proposals
--------------
The main idea is integrate both unit and functional testing for both C-based
and Perl-based programs. If new utilities appear in other languages, of course
the tests for them should be integrated in the same system.
Right now both proposals are proofs of concept with examples of C
unittesting[1] and Perl utilities functional testing [3]. One of the most
important features of the system would be _not_ to force the developers to
write all the testing code themselves: when possible, micro-formats, simple
text files, macros and other tools will be used to ease common cases.
Second proposal
---------------
Uses Test::Unit, a xUnit-style module for Perl. The main advantage over the
first proposal are: (1) more dpkg hackers know Perl than Tcl, and (2) we
already have Perl code in the dpkg codebase (related utilities as
dpkg-parsechangelogs), so it's easier to integrate unit tests for those cases.
Another advantage is that xUnit is very well thought, and that probably most
testing-aware guys know xUnit in _some_ language, so they will be more
comfortable with a xUnit-style solution.
It's available in a Darcs repo, at http://www.demiurgo.org/darcs/testsuite/
More info in http://lists.debian.org/debian-dpkg/2006/10/msg00000.html
First proposal
--------------
Uses DejaGNU[4], written in Tcl. I don't like the language, either ;-) I tried
with DejaGNU because it was supposed to have the "different kinds of tests
integration" thing already solved, but I'm not sure that's that hard to do
ourselves.
It's available in an Arch/Bazaar repo, at
http://people.debian.org/~zoso/arch/dpkg--test--1.0/
------------------------------------- >8 -------------------------------------
HTH,
[1] I.e., making calls to specific functions or modules; I'm using the check[2]
library for this
[2] http://check.sourceforge.net/
[3] http://www.gnu.org/software/dejagnu/
[4] I.e., executing programs with some parameters and see if they behave
correctly
--
Esteban Manchado Velázquez <[EMAIL PROTECTED]>
EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
Help spread it through the Net in signatures, webpages, whatever!
signature.asc
Description: Digital signature
