Re: Testcases for append! in greg style.

[Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>]

On 23 Mar 2000, Jim Blandy wrote:

> >    I used greg in order to offer an example based on which it can be
> >    decided whether it would make sense for guile to let greg be the
> >    standard test suite library.  If the decision is, not to use it, I will
> >    change the append! test cases accordingly.
> 
> Someone pointed Greg out to me shortly after I wrote the first bunch
> of Guile tests.  I think the Guile test framework has some advantages
> over Greg (e.g., reporters, nested names), and I guess I haven't
> really been persuaded that Greg has many advantages over (test-suite
> lib).
> 
> I also find code written with (test-suite lib) more readable, but if
> others don't agree, or prefer Greg for other reasons, I'm open to
> persuasion.

I have a couple of reasons why I like greg:
* It's easy.  With respect to providing test cases for guile itself,
  there's only one primitive to learn and you're done.
* Its maintenance is an SEP (somebody else's problem).
* It has some documentation

Besides this, it provides expect like testing of tools that don't support
guile, but a command line interface.

However, it's not perfect yet, though:
* the default assumptions that there is a directory with test cases and
  that all of these are called .scm and such are a little bit weirt
  IMO.  I'd rather like to give a set of files as command line parameters
  to greg.
* documentation could be improved. (But, until recently sombody from the
  guile community should not have dared to tell others about
  documentation :-)
* you're right about readability:  there could be some macros added in
  addition to greg-testcase.

These things can be fixed and some parts of guile's test framework can
probabyl most easily added.  Another point in favor of greg is, that it
is an indirect means to help a guile tool establish itself as a standard.

But, for me holds the same:  I'm not religuious about the topic.  Guile's
current test suite is also quite nice.  Could benefit from some
documentation, though.

> >    The solution was to store _every_ object of x in a separate structure
> >    before the operation is applied.  Thus, each cell as well as its
> >    contents are stored.  After the operation is performed, compare the new
> >    value of x with the set of its original elements.
> 
> Ahh, how I love lisp.

Probably I reinvented the wheel? :-)  Maybe I sounded too enthusiastic
about what I did:  I just wanted to provide some explanation for the
code, which otherwise might seem quite strange.

Maybe that's something that a scheme programmer should not say if he does
not want to make a fool of himself, but I say it:  I don't know
lisp.  Okay, I do know elisp (and like it, but not as much as scheme), but
I still don't get what you mean with your reference to lisp.

Best regards
Dirk Herrmann