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