This page is part of the web mail archives of SRFI 64 from before July 7th, 2015. The new archives for SRFI 64 contain all messages, not just those from before July 7th, 2015.
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 ( d.kolbly@xxxxxxxxxxx ( http://www.rscheme.org/~donovan/