This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Testcases for append! in greg style.


Hello!

I send the message below to the developers list, but was asked to provide
it for the whole community.  However, in order not to spam everybody with
about 20k of testing code, I rather will send it to you on request per
email

 ---------- Forwarded message ----------
Date: Thu, 23 Mar 2000 12:54:38 +0100 (MET)
From: Dirk Herrmann <dirk@ida.ing.tu-bs.de>
To: Guile Developers List <devel-guile@red-bean.com>
Subject: Testcases for append! in greg style.

Hello.

Below is a small set of test cases for append!.  There are two interesting
points about it:

1) I used greg as the testing library.  Fairly easy, as can be seen from
   the test cases.  The difference to guile's current lib is, that you
   provide the expected outcome of the test as a parameter.

   so, instead of 
     (pass-if "test-name" ...)
   you write 
     (greg-testcase "test-name" #t (lambda () (...))
   to indicate that the test is expected to pass.  #f means that the test
   is expected to fail.
     (pass-if-not "test-name" ...)
   thus has to be written
     (greg-testcase "test-name" #t (lambda () (not (...)))

   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.

   Probably it's easy to provide a macro that transforms the different
   styles into each other, but I am no macro guru.

2) Some of the test cases test exhaustively whether an object had been
   changed or not.  There are two functions provided:  unroll and
   diff-unrolled, which in combination allow to figure out whether some
   element of a complex object was modified.

   The problem that was to be solved was the following:  How can I verify
   for some object x, that after some operation on x all elements of x are
   still the same (with respect to eq?), i. e. that the operation treats x
   as const?

   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.

   The nice thing about this implementation is that it also handles
   circular structures.

I have, however, made some assumptions about changes that ought to be
performed:
a) currently, guile reports a misc-error when a circular list is illegally
   given as a parameter.  I feel that this is basically just a
   wrong-type-arg and have the testcases written to expect that a
   wrong-type-arg will be reported.
b) append! does still allow improper lists as arguments on other but the
   last position.  I do have a fix for that, but I would like to clarify
   some points about that fix before applying it.

So if you are interested, take a look at the test cases and greg.  If you
can provide a macro that would allow to use this test suite even with
guile's current test-suite lib, this would be great, because the tests
could be put into the test suite without modification then.

Best regards
Dirk Herrmann


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]