Re: duplication of SRFIs

[Sebastian Egner <sebastian.egner@xxxxxxxxxxx>]

Per Bothner wrote:
> What can I say: I'm annoyed.

I am sorry to learn that you take this
SRFI personal.

This SRFI is put forward as a simple
library for doing a primitive
form of running examples or embedding
assertions; there is very
little emotional load associated with
it on my side.

> Of course the SRFI processes *allows*
duplicate "standards",
> but clearly that should be undesirable,
except in the case of
> documenting existing practice.
 That is not the case with
> SRFI-64 vs -78, as far as I know.

Then please read section "Rationale"
of this SRFI again. As I explain,
one of the motivations for this SRFI
is that there is some existing
practice with this approach to testing.
Moreover, it is so simple and useful
that it is bound to pop up in lots of
other places as well. Since the feature
started to evolve in parallel with the
SRFIs in which it is used, I spent the
time to isolate and expose it as a feature
in its own right.

> One of the reasons for SRFI-64
is that I think the Scheme world
> needs a standard for test-suites:
Specifically,there should be can
> expectation that SRFIs should come
with a portable suitesuite.

SRFIs come with whatever the authors
choose to include, within the limits
of the SRFI process, and nothing more.
Having any other expectation is
self-deception or wishful thinking.

If the authors of a SRFI choose to include
some testing code for their
reference implementation that is great,
but should by no means be
'expected' by you or anybody else. It
should be even less expected
that the authors of a SRFI choose SRFI
64 (or SRFI 78 or any other SRFI)
as their framework for testing, just
because you put it forward as the
"standard for test-suites."
In the current situation, exactly nothing should
be taken for granted in the context
of SRFIs, or Scheme in general.

> [...] that SRFIs should come with
a portable suitesuite.
> That becomes a lot less likely
when we have competing SRFIs.

Does it? I disagree. It becomes a lot
less likely when the tools that are
available are not the ones somebody
would like to use---and this holds
independently of the relative merits
of one approach or the other or
the presence of alternatives.

> > The mechanism in this SRFI
does not replace more sophisticated
> > approaches to unit testing,
like SRFI 64 [1] or SchemeUnit [2].
>
> Do you really believe that? 

Yes.

When SRFI 64 came out, I took it as
a first step towards an 'industrial
strength' testing environment for Scheme.
This is not the intention with
SRFI 78, never was, and never will be.
I did not even occur to me that
you intend to put SRFI 64 forward as
'the one and only' testing mechanism.

> People are going to choose one
syntax
> for a test-suite and having multiple
APIs makes it less likely people
> will write testsuites.

Again, I disagree. You are assuming
people are stupid and behave
randomly, and so it is a matter of chance
if test-suits get written. This is
not the case. Many people are consistently
lazy. Tests get written when
it is either not a burden, or when it
is undeniably necessary.
My main problem with SRFI 64 is that
I do not want to learn about all the
nice little things you define like XPASS
etc.

> Why would you want a "lightweight
testing" framework and a separate
> "sophisticated testing"
that are incompatible?

Now that is indeed a good question.
If the approaches can be reconciled,
that could be useful. The only thing
that I need from a testing framework is:
CHECK and CHECK-EC as specified in SRFI
78 and a way to print the report
'here and now' without any setup or
any concepts like a test runners etc.
Controlling the verbosity of output,
switching off the tests, and dealing with
test runners explicitly, groups of tests
etc. is all more advanced stuff that I
want to be able to bring in when it
becomes unavoidable. One other thing I
noticed is that it is useful to print
test results immediately when they become
available one by one, this gives you
a way of tracking things up to a crash.

Concerning syntax, I wrote thousands
of CHECK/CHECK-EC-expressions,
and I got used to the '=> syntax,
i.e. (check (+ 1 1) => 2); in my opinion it is
the most obvious. Usually, I am a strong
proponent of 'strictly prefix' syntax,
but in this case I am in favor of '=>
as a syntactic keyword. Your TEST-EQUAL
looks a lot more like "What was
that again?"

Concerning CHECK-EC, the comprehension
has proven extremely useful
(read: "addictive") for writing
parametric tests. 

Do you see any way of incorporating
this stuff into SRFI 64? If so, how would
you go about it? If not, what would
be the problem?

The other way around, i.e. incorporating
most of SRFI 64 functionality into
SRFI 78, does not make too much sense
to me. SRFI 78 should remain
'lightweight' by any means. Either way
it probably is no harm in proceeding
with both SRFIs anyhow---getting them
right and correct in the first place.

Well, so much for now,

Sebastian.