Meta-test suite
Donovan Kolbly
(09 Mar 2005 17:54 UTC)
|
Re: Meta-test suite
Per Bothner
(09 Mar 2005 19:19 UTC)
|
Re: Meta-test suite
Donovan Kolbly
(09 Mar 2005 20:19 UTC)
|
Re: Meta-test suite
Per Bothner
(09 Mar 2005 20:39 UTC)
|
Re: Meta-test suite
Donovan Kolbly
(09 Mar 2005 21:21 UTC)
|
Re: Meta-test suite Per Bothner (09 Mar 2005 21:39 UTC)
|
Counting [was Re: Meta-test suite]
Donovan Kolbly
(10 Mar 2005 15:02 UTC)
|
Re: Meta-test suite
Per Bothner
(09 Mar 2005 20:41 UTC)
|
Re: Meta-test suite
Donovan Kolbly
(09 Mar 2005 20:54 UTC)
|
Donovan Kolbly wrote: > So that, suppose: > > (test-begin "a") > (test-begin "b") > (test-assert "x" #t) > > then in an on-test hook executing for the test-assert, we have: > > (test-runner-test-name runner) ==> "x" > (test-runner-group-path runner) ==> ("a" "b") Yes. > Although, then a custom runner would have no way to know about an empty > group. > > Would you intend that, for a custom runner, the following are > indistinguishable: > > (test-begin "a") > (test-assert "x" #t) > (test-end) > (test-begin "a") > (test-assert "y" #t) > (test-end) > > vs: > > (test-begin "a") > (test-assert "x" #t) > (test-assert "y" #t) > (test-end) I do think we should have call-back routins for test-begin/test-end. For example a test-runner might want to write in a log: [Entering group a] Test x PASS. [Exiting group a] [Entering group a] Test y PASS. [Exiting group a] > A "test suite" is a collection of "test cases" optionally organized into a > hierarchy of "test groups". A "test group" may be either implict, as > introduced by test-begin and terminated by test-end, or explicit, as > introduced by test-group. Agreed. > Furthermore, note that the tests within an > explicit test group may be skipped using test-skip, but this is not true > for tests within an implicit test group. > > [I think it's wierd that you can't skip an implicit test group, just for > symmetry. Although I can't see implementing it so that all the forms are > skipped, it might make sense to actually skip *tests* inside a skippable > implicit group.] I'm inclined to agree. I don't think the reference implementation does it this way, but it should be difficult to fix. For test-match-nth, should be count both the test-group/test-begin *and* (assuming the test-group/test-begin is not skipped) the tests in it? (test-skip 2) ;; Define this to mean skipping the 2nd following test. (test-begin "a") (test-assert "x1") (test-assert "x2") (test-end "a") (test-assert "x3") Should we skip "x2" or "x3"? I.e. do we count 1 for "a" as a unit, or 1 for "a" and 1 each for "x1"..."x3". The latter might be a little strange, but perhaps more convenient - and easier to implement, since we can use a single global counter. > For the purposes of test counting as checked by test-end, a test group (of > either variety) counts as a single test. I'm open to discussion on this: perhaps it should count as a single test *if it is skipped*. > Note that the registered on-test > procedure is not involved in test group boundaries, which means that the > sum of (test-runner-*-count) may be larger than the number of calls to the > on-test procedure. Yes, I think so. I we add test-begin/test-end call-backs, as I think we should, we might be able to be more specific. > Furthermore, if an explicit test group is skipped, the > group as a whole is skipped, not each test within it, which means that > (test-runner-skip-count) may be *smaller* than if the tests were > individually skipped. This seems unavoidable. -- --Per Bothner xxxxxx@bothner.com http://per.bothner.com/