2699c4c41f
2003-11-13 Not Zed <NotZed@Ximian.com> * camel-mime-parser.c: Remove mempool code, we use the stuff in e-util. (PRESERVE_HEADERS): new compile option, if on, we preserve headers and folding exactly rather than unfolding all input. THIS BREAKS EVERYTHING right now, so don't turn it on. * camel-gpg-context.c (gpg_decrypt): reset the input memstream before passing it to the gpg engine. * tests/smime/pgp-mime.c (main): redirect /dev/null to stdin so it doesn't hang waiting for input. (main): removed from build - this tests multipart/signed explictly, but now the details of this is handled directly by the cipher context. * tests/smime/pgp.c (main): fixes for api changes. (main): redirect /dev/null to stdin so it doesn't hang waiting for input. * tests/message/test1.c (main): update for api changes. * camel-smime-context.c (sm_verify): look at the content object's mime type, not the container's type. svn path=/trunk/; revision=23343
This directory is to contain regression tests that should be run before committing anything to camel. In each subdirectory of tests there is a README containing a one-line description of each test file. This README must be kept uptodate. To write a new test: copy an existing one and replace the contents. See camel-test.h for a number of functions and macros which setup and define the test environmet, and help provide meaningful messages when something actually fails. All tests have the following options: -v[vvvv] verbose. more v's more verbose. 2 v's will give you a simple test backtrace of any partially failed tests. No v's give you a simple backtrace of any failed tests. -q quiet. Dont print anything, unless there is a SEGV. See the other files in lib/* for utility functions that help to write the tests (object comparison, creation, etc functions). Tests may fail and be non-fatal. In this case, you will see "Partial success" on the result of each test line. To get more information about the test, run the test manually with a -v command line argument. The more v's you have the more detail you get (upto about -vvvvv), generally use -vv to find out which parts of a partially successful test failed, and where. Note that if writing tests, non-fatal tests (bracketed by a camel_test_nonfatal() and camel_test_fatal() pair) should only be defined where: 1. The test in question should ideally pass, and 2. The code has known limitations currently that stop it passing, but otherwise works for nominal input. To debug tests, set a breakpoint on camel_test_fail, which will be called for any failure, even a non-fatal one. Or set it to camel_test_break, which will only be called for fatal errors which are to print to the screen. Michael <notzed@helixcode.com>