[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Static ambiguities: test-end and test-apply
On Thu, 24 Mar 2005, Donovan Kolbly wrote:
> > >
> > > (test-apply [runner] specifier ... thunk)
> > > Furthermore, if test-apply were made to require the runner (the user could
> > > supply (test-runner-current) if needed), this would also solve the
> > > "implicit runner" problem (*).
> > No objection to making the runner non-optional
> > If test-apply creates a new runner, then it should also finalize it.
> > Just like test-group/test-begin+test-end do. Am I missing something?
> > It probably is convenient to have a short-hand to run a specific set of
> > tests with a default runner being created and finalized. The use case
> > I'm thinking of debugging a test-suite or a specific test.
I went to implement these and realized I wasn't paying attention to the
interaction between them.
How about a separate 'test-run' which is like test-apply but always
creates a new runner (using the current factory) to do so, and then
(test-run spec ... form)
with the added feature that the caller may supply zero (0) specs, in which
case all tests are run (which is a special case, because the degenerate
case which would cause no tests to be run)
and then test-apply never creates a group contour, and either (a SRFI
specification time choice) (1) only makes sense when there is already a
(test-apply spec ... form)
(useful for doing the inverse of test-skip)
or, (2) always takes a runner argument:
(test-apply runner spec ... form)
and in either case, at least one spec must be supplied.
-- Donovan Kolbly ( d.kolbly@xxxxxxxxxxx