[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Automated testing - design and interfaces



to, 2005-11-17 kello 18:43 +0000, Ian Jackson kirjoitti:
> Note: that this is one of two messages on roughly the same topic.
> 
> This message will deal solely with TECHNICAL issues.  If you have some
> technical followup then please go ahead and reply here.  If you have a
> complaint or comment about my or Ubuntu's approach, please reply in
> debian-*project* to my other message, titled `Automated testing -
> politics, information, and Ubuntu's plans'.

My program, piuparts, has been mentioned in this thread, and I feel I
should comment. I started writing a reply, and it grew and grew, and I
don't have the time to finish it until next week at the earliest (I'm
going to be away this week). I will however offer the following brief
remarks and perhaps next week I'll see that my long response isn't
needed at all.

1. I think Ian and Ubuntu are correct in that automatic testing is a
good thing and should be done more. We can squabble over implementation,
and there's a few things buzzing in the back of my brain that want to
claim that Ian's approach needs some tweaking, but until and unless I
figure things out I am not going to stand in the way of progress, even
if it doesn't go quite in the direction my gut feeling says it should
go. If Ian (or others) gets it wrong, we can fix it in the next
iteration. No worries there.

2. If it turns out that having piuparts run the tests is technically a
good idea, I'm all for it.

3. The Debian QA team is somewhat disorganized and understaffed. It
would be great to get a good, active team. For example, I've been
writing and running piuparts pretty much in isolation, and I know at
least one or two other people have also been running it. We should join
forces, and gather more people besides, so that by the time etch freezes
next year, we WILL ALREADY HAVE FOUND ALL THE BUGS! Hopefully fixed them
as well, but I see QA's primary role being a tester, a finder of
problems, which the general developership then fixes.

4. As a design principle, if it is possible to have generic tests rather
than have every package add thoses tests themselves, we should go for
the generic tests.

I'll be happy to continue this discussion next week. If, meanwhile,
everyone else continues it and solves every possible problem, I will be
more than happy. I will be positively espanglished!

-- 
Choose wisely, choose often.



Reply to: