On Fri, Mar 4, 2011 at 10:11 AM, Neil Van Dyke <neil at neilvandyke.org> wrote:
> Could someone explain the advantages of having, say, the "test-suite" form
> produce a data structure to be supplied to test-runner code... rather than
> having evaluation of the "test-suite" form result in the tests actually
> being executed?
Since test (suites) are values you can change how you run them. E.g.
log the results to disk, or draw pretty graphs.
> Regarding the latter alternative, I had in mind a simple model, closer to
> Racket language model, in which there is a *test run context*, represented
> as a Racket language parameter. Evaluating a "check" form results i its
> test being executed, and it then simply calls back to code in the test run
> context to report the result of the test.
These contexts exists in RackUnit (read the docs ;-P) You can write
(test-case "..." ...)
(check ... ... ...)
and your tests will run. I.e. they are expressions. Essentially test
suites convert expressions to values.
> This question is important to me because, if the unified foundation for
> building test suites has a model similar to that of RackUnit, I'm not sure
> that's the desired model.
If you check out the code I put on Github, it has broadly the model
you're suggesting.
HTH,
N.