This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Testcases for append! in greg style.
- To: Guile Mailing List <guile at sourceware dot cygnus dot com>
- Subject: Testcases for append! in greg style.
- From: Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>
- Date: Fri, 24 Mar 2000 01:57:33 +0100 (MET)
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