Files
evolution/camel/tests
Not Zed 6de256c2a2 Lock the command channel while searching. (imap_body_contains): If
2000-12-24  Not Zed  <NotZed@HelixCode.com>

        * providers/imap/camel-imap-search.c (imap_body_contains): Lock
        the command channel while searching.
        (imap_body_contains): If performing a whole uid search, then add
        references to our own summary items, dont look it up in the
        folder.  This way they can't vanish unexpectedly.

        * providers/imap/camel-imap-folder.h (CamelImapFolder): Added a
        private field.

        * providers/imap/camel-imap-private.h: Added lock for imap
        searches.

        * Merge from camel-mt-branch.

        * providers/imap/camel-imap-folder.c (imap_update_summary): Merge
        fix, use the folder->summary.
        (imap_get_message_flags, imap_set_message_flags,
        imap_get_message_user_flag, imap_set_message_user_flag): Removed
        again.
        (camel_imap_folder_init): Setup private data/lock.
        (imap_finalize): Free private data/search lock.
        (imap_search_free): Lock the search_lock.
        (imap_search_by_expression): Lock the search lock when using the
        search object.  Also copy/ref hte summary, rather than getting it
        directly.
        (imap_refresh_info): Free any info lookups.  Use folder->summary
        not imap_folder->summary.  And lock around commands.

svn path=/trunk/; revision=7150
2000-12-24 00:46:20 +00:00
..
2000-12-08 18:06:19 +00:00
2000-12-08 17:55:42 +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>