6b132fe48a
2002-08-29 Not Zed <NotZed@Ximian.com> * tests/folder/test3.c: Change the case sensitive search of subject to expect case insensitive results, as the behaviour has changed. (main): Made the search content before sync nonfatal. its something that needs to be fixed but not practical concern in evolution. * camel-block-file.c (block_file_validate_root): Only spit out the invalid root warnings if the file isn't empty. * camel-text-index.c (text_index_compress_nosync): Swap the path as well when we compress. * camel-mime-parser.c (folder_scan_content): Treat the end of file as a boundary if we're scanning From lines, and drop the last \n. (folder_scan_init_with_fd): Dont pre-read from the fd, and init eof. (folder_scan_init_with_stream): Similar. (folder_read): Handle eof, and set eof on 0 read. (folder_seek): Dont pre-read after a seek, and reset eof flag. (camel_mime_parser_init_with_fd): Fix doco, no pre-read occurs anymore. (camel_mime_parser_init_with_stream): Same. * providers/local/camel-mbox-summary.c (camel_mbox_summary_sync_mbox): Add a \n to end of content of each message, not at start. * providers/local/camel-mbox-folder.c (mbox_append_message): Instead of appending "\nFrom " to a mailbox, start with "From ", and append a \n after the message always. For better mutt/elm compatability. Also, unlock after we've stat'd. (mbox_append_message): Set the message's from_pos exactly as the mbox size. svn path=/trunk/; revision=17921
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>