- From: olivier Thereaux <ot@w3.org>
- Date: Fri, 22 Oct 2004 11:54:11 +0900
- To: QA Dev <public-qa-dev@w3.org>
- Message-Id: <A6A6CA22-23D5-11D9-8317-000A95E54002@w3.org>
On Oct 22, 2004, at 0:21, Bjoern Hoehrmann wrote: > With the outlined framework there would not really be "test cases" but > rather "tests" where is "test" is generally Perl code I think this is fine for testing the guts of the software, but in our case, we have to test a piece of software that happens to be a testing tool, and that I think goes beyond testing every loop, object, nook and cranny, it also means testing the logic of the software versus the test. That's what we have /dev/test/ for. Granted, now that I have looked more extensively at all the stuff in qa.perl.org I see that we can do most of that automatically, event gracefully, with Test::Builder and co, (also noticed WWW::Mechanize which may be of some interest). > This includes the input data directly in the code, no meta data, no > organization, no management, no re-use, ... so it would seem you would > consider this much worse than the worst of your proposed solutions. As a matter of fact, I consider that very similar to one of my proposed solutions, although worded differently. I would not be extremely comfortable with a test suite that does not have at least some documentation, dating and describing the test cases, allowing to tie a test case (or more) to an item in bugzilla or a thread on w-v, etc. Which does not mean it can't be done simply with commented out lines in the code. That's cheap and easy. That would make it hardly possible to have any kind of (HTML or otherwise) documentation of the test suite, which is a pity, but something I could live with. -- olivier
Received on Friday, 22 October 2004 02:54:22 UTC