On 09/24/2015 01:26 AM, Taylan Ulrich Bayırlı/Kammer wrote:
> Per Bothner <xxxxxx@bothner.com> writes:
>
>> Do you have a plug-in replacement for Kawa's gnu/kawa/slib/testing.scm?
>> I gather so, since you've tested it.
>
> One is in the attachment.  I didn't note down the steps I had to take,
> but from memory it should be roughly:
>
> - concatenate the *.body.scm files in the order: test-runner, execution,
>    source info, test-runner-simple,
> - add "else" clauses to 'case' expressions,
> - add "require" and module export boilerplate,
> - define and export %test-begin as a synonym to test-begin,
> - move some definitions to before their first use.

I just checked in a fix to Kawa to allow macros to have forward definitions.
This is more complicated than you might think, because you also want to be
able to use a macro in the same scope/module it is defined in.  The solution was
to the processing (macro-expansion and name-resolution etc) of the macro body
lazily.

I was able to replace testing.scm by a bunch of include forms.
That would be cleaner.  Better yet is to support both the library
forms and the traditional automatic-use, without runtime cod duplication,
but that should be too difficult.

Some concerns:

* I still don't see any line number information in the output.

* I think I'd much rather see (current reference output):

./r7rs-tests.scm:494: FAIL

than:

[FAIL] R7RS/4.3 Macros/val

though a combination might be even better:

./r7rs-tests.scm:494: FAIL (R7RS/4.3 Macros/val)

Note having the line number first, and with this syntax, is both
traditional and handled better by tools such as Emacs.

If line numbers aren't available, the following works:

FAIL (R7RS/4.3 Macros/val)

If you really prefer the square brackets, the following are acceptable:

./r7rs-tests.scm:494: [FAIL] R7RS/4.3 Macros/val
[FAIL] R7RS/4.3 Macros/val

* The log file should report both expected and actual result values, at
least in the case of failure.

* The current reference implementation also reports in the log file
the source-form, but that is probably not as important or useful

* The standard output should only report unexpected failures (and passes),
so to make runs "more quiet".  That's the reason for the log file: to be able
to look at the details *when you want/need to*, not all the time.

*I'd also skip (at least in standard output) the summary lines with count 0,
and the group begin/end messages.

--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/