[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: duplication of SRFIs

This page is part of the web mail archives of SRFI 78 from before July 7th, 2015. The new archives for SRFI 78 contain all messages, not just those from before July 7th, 2015.

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?


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,