Donovan Kolbly wrote:
> In general, I don't care as much about the order of arguments, but I do
> find it's better to ascertain the meaning of an invocation with no more
> work than counting the number of arguments (i.e., not having to examine
> the type of the arguments).

I'm used to Java (and C++) overloading so I may have more tolerance for
selecting depending on argument types.

> In the current spec, test-end is ambiguous:
>
>   (test-end [name] [count])

I'm thinking about moving the count to the test-begin.  That might be
helpful for a test-runner that displays a progress bar, for example:

(test-begin name [count])
(test-end [name])

But in that case should test-group also have a count?

(test-group name [count] form ...)

> as is test-apply:
>
>   (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 - it's not like
people will be writing lots of test-apply calls.

> (*) The "implicit runner" problem:  there are currently two forms which
> can implicitly create a runner: test-begin and test-apply.  It's obvious
> how to "finalize" (bring about the invocation of the on-final hook) one
> created by test-begin, but it's less clear how that should happen for
> test-apply.  In fact, this is a real problem for my current
> implementation!

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.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/