[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Static ambiguities: test-end and test-apply
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])
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
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.