Files
evolution/camel/tests
Michael Zucci 05aaadc66b little util to scan mailboxes for any and every address they contain.
* tests/data/getaddr.pl: little util to scan mailboxes for any and
	every address they contain.

	* tests/message/test2.c (main): Added a bunch of stuff to test
	decoding/reencoding/etc of internationalised addresses.

	* tests/message/lib/address-data.h: Copy of some unicode/other
	testing data.  **Beware** of editing this file in emacs, it'll
	probably try and convert all the characters to something
	unusable.

	* tests/lib/camel-test.c (camel_test_break): Add a debugger hook
	point.

	* camel-mime-utils.c (quoted_encode): Check for space and convert
	to _ separately.
	(header_decode_mailbox): Fixed the 'check comments for realname'
	code, problem was the domain getting code was skipping all
	whitespace/comments before we could get a look-in.  This is
	approximate but fairly robust.
	(header_decode_text): Dont use the c-type isspace func here, we
	want a specific whitespace only.
	(header_decode_text): If we have decoded words next to each other,
	do not insert whitespaces between them, which is what rfc2047 requires.
	(header_decode_text): Make c unsigned too.

svn path=/trunk/; revision=6658
2000-11-24 07:06:45 +00:00
..
2000-11-24 03:18:20 +00:00

This directory is to contain regression tests that should be run
before committing anything to camel.

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>