We *really* need a development model change !

Alexandre Julliard julliard at winehq.com
Wed Jan 2 17:18:31 CST 2002


Andriy Palamarchuk <apa3a at yahoo.com> writes:

> 1) look at file test1.pl. It implements exactly the
> functionality of existing test.pl module with using
> Test::Simple framework. The only change I made are
> descriptive error messages for the first few tests. 
> 
> Output of test1.pl:
> ok 1 - Valid atom handle
> ok 2 - No error code defined
> ok 3
> ok 4 - Succeed code
> ok 5 - Atom name
> ok 6
> ok 7
> ok 8
> ok 9
> ok 10
> ok 11
> ok 12
> ok 13
> ok 14
> ok 15
> 1..15
> 
> The basic usage is not more difficult than one you
> suggested, right?

Yes, using ok() or assert() is pretty much the same. But it should not
be printing all that stuff IMO, except if you explicitly ask it to
when debugging a test for instance. The TODO/SKIP stuff is
interesting, I agree we probably want something like that.

> 3) Things become even more interesting when
> Test::Simple is used with module Test::Harness.
> Test::Harness allows to run many tests at once and
> consolidate results of these tests.
> test_all.pl uses the module to run all the tests
> (currently test2.pl only). The output of the script:
> 
> test2.p.............#     Failed test (test2.pl at
> line 8)
> # Looks like you failed 1 tests of 4.
> dubious
> 	Test returned status 1 (wstat 256, 0x100)
> DIED. FAILED tests 2-3
> 	Failed 2/4 tests, 50.00% okay
> Failed Test  Status Wstat Total Fail  Failed  List of
> failed
> -------------------------------------------------------------------------------
> test2.pl          1   256     4    2  50.00%  2-3
> Failed 1/1 test scripts, 0.00% okay. 2/4 subtests
> failed, 50.00% okay.

I really don't see a need for this kind of things. IMO we should
enforce that tests always succeed, otherwise we can't do regression
testing. And running the tests through the Makefile has the advantage
that you can check dependencies and only run tests when something
affecting them has changed.

-- 
Alexandre Julliard
julliard at winehq.com




More information about the wine-devel mailing list