Files
evolution/camel/tests
Not Zed 1a6fb9ab88 ** A few fixes for better rfc compliance, and cleaner code.
2004-06-01  Not Zed  <NotZed@Ximian.com>

        ** A few fixes for better rfc compliance, and cleaner code.

        * camel-mime-utils.c (header_encode_param): a bunch of logic
        cleanups with new util functions.
        (header_decode_init): setup a new type ATTR_CHAR, for
        attribute-char.

        * tests/misc/test2.c (main): new test for rfc2184 stuff.

        * camel-mime-utils.c (header_convert): helper to convert between
        charsets.
        (rfc2184_decode): fix a bunch of logic problems and use the helper
        above to simplify code.
        (decode_param_token): removed, not needed.
        (header_decode_rfc2184_param): removed, not needed.
        (header_decode_param): removed, not needed.  ugh.
        (header_decode_param_list): completely rewritten, hence lack of
        need of above.

svn path=/trunk/; revision=26140
2004-06-01 10:07:13 +00:00
..
2003-09-23 16:50:06 +00:00
2003-07-09 19:34:15 +00:00
2004-01-20 05:33:12 +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>