Files
evolution/camel/tests
Not Zed 2699c4c41f Remove mempool code, we use the stuff in e-util. (PRESERVE_HEADERS): new
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
2003-11-13 23:17:31 +00:00
..
2003-09-23 16:50:06 +00:00
2003-07-09 19:34:15 +00:00

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>