1
Fork 0
mirror of https://git.savannah.gnu.org/git/guile.git synced 2025-06-05 11:40:20 +02:00
guile/test-suite
2000-03-22 21:22:39 +00:00
..
tests * paths.scm: Assume that ~/guile-core/test-suite is the location 2000-01-16 22:03:44 +00:00
.cvsignore Ignore tmp[123] files 2000-01-26 01:26:30 +00:00
ChangeLog *** empty log message *** 2000-01-16 22:07:08 +00:00
COPYING Copyleft files. 1999-05-30 09:22:12 +00:00
guile-test Initial checkin of the Guile test suite. 1999-05-29 14:22:24 +00:00
lib.scm * lib.scm: Doc fixes. 2000-03-22 21:18:57 +00:00
paths.scm * paths.scm: Assume that ~/guile-core/test-suite is the location 2000-01-16 22:03:44 +00:00
README Add some test suite philosophy. 2000-03-22 21:22:39 +00:00

This directory contains some tests for Guile, and some generic test
support code.

To run these tests, you will need a version of Guile more recent than
15 Feb 1999 --- the tests use the (ice-9 and-let*) and (ice-9
getopt-long) modules, which were added to Guile around then.

To run the test suite, you'll need to:
- edit the path to the guile interpreter in `guile-test', and 
- edit the paths in `paths.scm', so `guile-test' can find the test
  scripts.

Once that's done, you can just run the `guile-test' script.  That
script has usage instructions in the comments at the top.

You can reference the file `lib.scm' from your own code as the module
(test-suite lib); it also has comments at the top and before each
function explaining what's going on.

Please write more Guile tests, and send them to bug-guile@gnu.org.
We'll merge them into the distribution.  All test suites must be
licensed for our use under the GPL, but I don't think I'm going to
collect assignment papers for them.



Some test suite philosophy:

GDB has an extensive test suite --- around 6300 tests.  Every time the
test suite catches a bug, it's great.

GDB is so complicated that folks are often unable to get a solid
understanding of the code before making a change --- we just don't
have time.  You'll see people say things like, "Here's a fix for X; it
doesn't cause any regressions."  The subtext is, I made a change that
looks reasonable, and the test suite didn't complain, so it must be
okay.

I think this is terrible, because it suggests that the writer is using
the test suite as a substitute for having a rock-solid explanation of
why their changes are correct.


Jim's rule for test suites:

Every test suite failure should be a complete, mysterious surprise,
never a possibility you were prepared for.  Any other attitude
indicates that you're using the test suite as a crutch, which you need
only because your understanding is weak.