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.

OK, so:

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
finalizes it.

  (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
runner:

  (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                    (  xxxxxx@rscheme.org
				     (  http://www.rscheme.org/~donovan/