If your testcases are behaving oddly, (but not crashing) then you want to turn on verbose output and/or debug output.
You can use the `--verbose' flag to make output more detailed, so you can easily tell at which testcase things start to go wrong.
You can use the `--debug' flag to get extra debug output written to a `.dbg' file. The information written to this file is that provided using the `greg-dlog' procedure (which merely prints all its arguments to the `.dbg' file when debugging is enabled.
For this to be useful, you simply add `greg-dlog' instructions to display pertinent information around the piece of code that is not behaving as expected.
Debugging of crashes is the area where the advantages of the Gstep-Guile/Greg test framework over Deja-Gnu/TcL really have an impact (apart from the obvious advantages of Guile over TcL).
Since `Greg' is primarily designed for embedded testing of libraries, it is very easy to debug testcases. The code being tested and the code performing the testing are in the same address space and it's therefore very easy to run the tests under gdb.
For debugging Objective-C code, you should really make sure you have gdb version 4.17 with the Objective-C patch - ftp://alpha.gnu.org/gnu/gnustep/contrib/gdb-4.17-objc-unoff-980505.patch.gz
If you are writing a testcase that is crashing, or you are running the test suite and something is crashing, you want to use gdb -
Type `gdb guile-base' to start the debugger.
Type `run' to start the guile command-line interpreter.
Type `(use-modules (ice-9 greg))' to load `Greg'.
Type `(set! greg-tools (list "foo"))' where `foo' is the
name of the class you are testing.
Type `(greg-test-run)' to run the tests.
Then wait for the crash and start debugging :-)
Go to the first, previous, next, last section, table of contents.