Instead of generating auxiliary run_emacs script every time
test_emacs is run, do it once in the beginning of the test.
Also, use absolute paths in the script to make it more robust.
Using `setq' for setting variables in Emacs tests affect other
tests that may run in the same Emacs environment. Currently it
works because each test is run in a separate Emacs instance. But
in the future multiple tests will run in a single Emacs instance.
The patch changes all variables to use `let', so the scope of the
change is limited to a single test.
Few Emacs tests used sed(1) to remove unexpected output in the
beginning to avoid getting confused by messages such as "Parsing
/home/cworth/.mailrc... done". This is no longer needed since
tests are run in a temporary home directory instead of the user's
one. So remove these sed(1) calls.
Before the change, the common Emacs test scheme was to print
buffer content to stdout and redirect it to a file or capture it
in a shell variable. This does not work if we switch to using
emacsclient(1) for running the tests, because you can not print
to the stdout in this case. (Actually, you can print to stdout
from Emacs server, but you can not capture the output on
emacsclient(1)).
The patch introduces new Emacs test auxiliary functions:
`test-output' and `test-visible-output'. These functions are
used to save buffer content to a file directly from Emacs. For
most tests the changes are trivial, because Emacs stdout output
was redirected to a file anyway. But some tests captured the
output in a shell variable and compare it with the expected
output using test_expect_equal. These tests are changed to use
files and test_expect_equal_file instead.
Note: even if we do not switch Emacs tests to emacsclient(1), the
patch makes tests cleaner and is an improvement.
Most test_emacs calls have long arguments that consist of many
expressions. Putting them on a single line makes it hard to read
and produces poor diff when they are changed. The patch puts
every expression in test_emacs calls on a separate line.
Few Emacs tests had test_expect_equal_file arguments in the wrong
order: the first argument should be the test output and the
second one should be the expected.
Update the test mail corpus to have two files with the same content to
expose the bug where a single message with multiple filenames only
reports a single filename.
Update expected results for search --output=files to match new
behavior for multiple files corresponding to a single message
Signed-off-by: Mark Anderson <ma.skies@gmail.com>
Various typo fixes in some test-case data.
Signed-off-by: Pieter Praet <pieter@praet.org>
Edited-by: Carl Worth <cworth@cworth.org> Restricted to just
test-case data.
Various typo fixes in documentation within the code that can be made
available to the user, (emacs function help strings, "notmuch help"
output, notmuch man page, etc.).
Signed-off-by: Pieter Praet <pieter@praet.org>
Edited-by: Carl Worth <cworth@cworth.org> Restricted to just
documentation and fixed fix of "comman" to "common" rather than
"command".
Various typo fixes in comments within the source code.
Signed-off-by: Pieter Praet <pieter@praet.org>
Edited-by: Carl Worth <cworth@cworth.org> Restricted to just
source-code comments, (and fixed fix of "descriptios" to "descriptors"
rather than "descriptions").
Various typo fixes in comments within the Makefile and other build scripts.
Signed-off-by: Pieter Praet <pieter@praet.org>
Edited-by: Carl Worth <cworth@cworth.org> Restricted to just build files.
Various typo fixes in auxiliary text files included with the source,
(README, TODO, etc.).
Signed-off-by: Pieter Praet <pieter@praet.org>
Edited-by: Carl Worth <cworth@cworth.org> Restricted to just text files.
We exercise each of the documented values (nil, a string, and a
list). For the list, we test matching a specific entry, matching a
catch-all regular expression, and no match at all (in which case there
is no FCC set).
The worry here is that a binary linking with libnotmuch might lose
access to Xapian::Error symbols because libnotmuch hides them.
We are careful here to create ./fakedb/.notmuch in order to trigger a
Xapian exception, and not just a missing file check.
Thanks to jrollins and amddragon for suggestions.
(cherry picked from commit 66f37f5f6864a988f94ddb893e3a176af57f6c8e)
The main() function should be written as just another function with a
return value. This allows for more reliable code reuse. Imagine that
main() grows too large and needs to be factored into multiple
functions. At that point, exit() is probably the wrong thing, yet can
also be hard to notice as it's in less-frequently-tested exceptional
cases.
Each top level test (basic, corpus, etc...) is run with a fixed
timeout of 2 minutes.
The goal here is to treat a hung test as a failure. The emacs test for
sending mail is known to be problematic on the Debian
autobuilders. This is both a bandaid fix for that, and a sensible long
term feature.
(cherry picked from commit 5f99c80e02736c90495558d9b88008a768876b29)
The intent was always to make these Received headers span multiple
lines. But the escapes were causing the shell to ignore the newlines,
so that the result instead was long Received headers on a single line
each.
Fixing the intent here doesn't actually change the test-suite results
at all.
This is much more realistic, as most messages in the wild will have multiple
Received headers. Also, this demonstrates a current bug in the Received
header parsing, (multiple Received headers are not properly concatenated
depending on the order in which headers are parsed in a message).
This tests the recently-added detection/hiding of top-posted quotations and
in the testing, it takes advantage of the less-recently-added
visible-buffer-string function for emitting only the visible text
from a buffer.
Again, this is a much cleaner and more thorough test, and in fact
exposes a bug in the format=text output, that will be fixed the next
commit. Because of this, some of the multipart tests currently fail.
This is a much cleaner way to do the emacs tests, since we're actually
comparing output against existing files with expected output. We also
won't miss any trailing newlines this way.
And speaking of which, one of the expected output files was actually
missing a trailing blank line that was actually in one of the original
messages, so this was fixed.
This feature was recently added, so it of course needs a test now.
Signed-off-by: Jameson Graef Rollins <jrollins@finestructure.net>
Edited-by: Carl Worth <cworth@cworth.org> Fixed test to use
notmuch_search_sanitize in order to be robust against unpredictable
thread ID numbers, (due to unpredictable order in which the filesystem
presents files).
In the master branch in test/emacs two tests access the build users home
directory, so does emacs_deliver_message in the crypto branch.
The tests should not touch the build user's home directory. The patch
creates a directory in the temporary test directory and sets home
accordingly.
In case of a non-existent home directory, the tests are failing without
this patch.
Signed-off-by: Jameson Graef Rollins <jrollins@finestructure.net>
This test doesn't have anything to do with json, and has everything to
do with testing search capability, so I'm not sure why it was in the
wrong place.
The "Search for non-existent message prints nothing" test fits better
with the existing tests in search-output, so move it there. Also add a
similar test for the --format=json case.
These tests also use the new test_expect_equal_file function, (to ensure
that the presence of a trailing newline is correctly tested).
These test now properly test for the presence of a newline at the end
of all output. Right now some of these test will fail because the
search output is currently broken to *not* produce proper newlines in
some cases.
Since commit 2f8871df6e notmuch has been
using a function (show_part_content) originally written only for text
parts to save all MIME parts. The problem with this is that this
function converts CRLF pairs to LF only and optionally converts to
UTF-8 encoding. These two conversions have the potential to corrupt
binary data when passed through the function.
This test demonstrates that corruption, and so fails currently, until
we fix the bug.
Not that it affects the correctness of the test, but it's nice to use
proper spelling. This kind of change could invalidate a signature on the
test message, but I think that would have happened previously when the
HTML part was added in the first place.
Use .gz filenames for saved attachments in the tests to check
that Emacs does not re-compress the file.
Use test_expect_equal_file instead of test_expect_equal to avoid
binary output on the console.
Before the change, test_expect_equal_file moved files it compared
in case of failure. The patch changes it to copy the files
instead. This allows testing non-temporary files which are
stored in git.
Note: the change should not result in new temporary files left
after the tests. Test_expect_equal_file used to move files only
on failure, so callers had to cleanup them anyway.
The primary goal here is to keep the decrypted output as similarly
structured as undecrypted output as possible. Now, when decrypting
parts, only the original encrypted part is replaced by the it's
decrypted content. If this part isn't itself a multipart, then all
part numbering should remain consistent during decryption.
The only draw back here is that the useless application/pgp-encrypted
sub-part of the multipart/encrypted part is also emitted. But this
part can be easily ignored by clients.
Some folks have complained about the part renumbering that occurs when
the entire multipart/signed part is replaced with the part contents
after verification. This is primarily because it incurs an additional
computational cost to retrieve individual parts, since verification
has to be performed again to ensure that part numbering is consistent.
This patch simply leaves the full multipart/signed part as is.
The emacs crypto test is also updated to reflect this change.
This patch adds the tag "signed" to messages with any multipart/signed
parts, and the tag "encrypted" to messages with any
multipart/encrypted parts. This only occurs when messages are indexed
during notmuch new, so a database rebuild is required to have old
messages tagged.
This adds a new "crypto" test script to the test suite to test
PGP/MIME signature verification and message decryption. Included here
is a test GNUPGHOME with a test secret key (passwordless), and test
for:
* signing/verification
* signing/verification with full owner trust
* verification with signer key unavailable
* encryption/decryption
* decryption failure with missing key
* encryption/decryption + signing/verfifying
* reply to encrypted message
* verification of signature from revoked key
These tests are not expected to pass now, but will as crypto
functionality is included.
We need to be able to test for the presence of a newline at the end of
output. There's no good way to capture trailing newlines in bash, so
redirecting output to a file is the next best thing. This new
function should be used when testing for output that is expected to
have trailing newlines.
The next commit will demonstrate the use of this.
The patch replaces all (message (buffer-string)) calls in emacs
tests with (princ (buffer-string)). This avoids accidentally
interpreting '%' as format specifiers and makes code simpler
because we do not need to capture stderr.
Also, the patch works around an Emacs (23.3+1-1 on current Debian
Unstable) segfault in "Ensure that emacs doesn't drop results"
test. Note: the segfault does not happen on every test run.
Though, it seems to be consistently reproducible if the test uses
300 messages instead of 30. Hopefully, it is the crash described
in Emacs bug #8545 [1] which is already fixed.
[1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8545
Change #!/bin/bash at start of tests to "#!/usr/bin/env bash". That way
systems running on bash < 4 can prepend bash >= 4 to path before
running the tests.
The patch adds test-lib.el file for Emacs tests auxiliary stuff.
Currently, it implements two functions: `visible-buffer-string'
and `visible-buffer-substring'. These are similar to standard
counterparts without "visible-" prefix but exclude invisible
text. The functions are not used anywhere at the moment but
should be useful for testing hiding/showing in the Emacs
interface.
Edited-by: Carl Worth <cworth@cworth.org> Fixed "basic" test to ignore
new test-lib.el file.
The example multipart message is made a bit more complicated by adding
a message/rfc822 message, and the all parts are output and tested in
all output formats.
Remove double quotes and flatten "foo@bar.com <foo@bar.com>" to
"foo@bar.com".
Edited-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net> (clean up
expected output for emacs tests).
Signed-off-by: Jameson Rollins <jrollins@finestructure.net>
The compilation of the smtp-dummy program would fail if a build was
attempted on a system without getline. Fix this by simply including
the existing notmuch_compat_srcs variable when constructing the list
of source files for compiling smtp-dummy.
Previously, notmuch show flattened all output, losing information
about the nesting of the MIME hierarchy. Now, the output is properly
nested, (both in the --format=text and --format=json output), so that
clients can analyze the original MIME structure.
Internally, this required splitting the final closing delimiter out of
the various show_part functions and putting it into a new
show_part_end function instead. Also, the show_part function now
accepts a new "first" argument that is set not only for the first MIME
part of a message, but also for each first MIME part within a series
of multipart parts. This "first" argument controls the omission of a
preceding comma when printing a part (for json).
Many thanks to David Edmondson <dme@dme.org> for originally
identifying the lack of nesting in the json output and submitting an
early implementation of this feature. Thanks as well to Jameson Graef
Rollins <jrollins@finestructure.net> for carefully shepherding David's
patches through a remarkably long review process, patiently explaining
them, and providing a cleaned up series that led to this final
implementation. Jameson also provided the new emacs code here.
Previously, the outer multipart part of any multipart/mixed,
multipart/signed, etc. MIME message was silently omitted from the
"notmuch show" output. This prevented any client from correctly
determining to which parts a signature applies, for example.
Now, we actually emit these parts as their own parts. The output is
still flattened---the contained parts are not yet included "within"
the multipart part---so it's still not possible to determine to which
parts a signature applies, but this is one step along the path.
The test suite is updated to reflect this change, (though we'll
eventually want to fix the emacs interface to not display buttons for
the multipart enclosure parts as there's nothing useful for the user
to actually do with them).
This tests "notmuch show" with both --format=text and --format=json on
a message with some non-trivial MIME multipart nesting, (multiple parts
within a multipart/mixed part which is within a multipart/signed part).
The test captures the current behavior (where only the leaf nodes of
the MIME structure are emitted as a flat list---the multipart parts
are effectively ignored). We plan to soon change the json output at
least to emit an actual hierarchy matching the MIME structure, (at
which point we will update this test).
Theses were expected failures only due to a bug in GMime (with
versions of GMime before 2.4.18). As of GMime version 2.4.18 this bug
is fixed and these tests now pass.
With the previous commit, unexpected output before or between search results
would be displayed. However, trailing junk from the "notmuch search" output
would still be silently swallowed.
The most common case for an error message from "notmuch search" would be
an invalid command-line, and in that case, there would be no search results
and the trailing error message would get swallowed.
We fix the process sentinel to check for leftover data and add it to the
final buffer. We also add a test case to ensure this works.
Rather than silently swallowing unexpected output, the emacs interface will now
display it. This will allow error messages to actually arrive at the emacs
interface (though not in an especially pretty way). This also allows for easier
investigation of the inadvertent swallowing of search results that span page
boundaries (as demonstrated by the recent added emacs-large-search-buffer test).
The page-boundary bug has been present since a commit from 2009-11-24:
93af7b5745
Many thanks to Thomas Schwinge for tracking that bug down and
contributing the test for it.
The new name is more descriptive of the bug being tested. Also, the test
is rewritten slightly so that it's much more plain to see how the bug
manifests itself, (that messages are droped from the emacs result at
regular intervals). Primarily, this is by collapsing the large blobs
used to inflate the message subjects.
In the original json code, search matching nothing would return a
valid, empty json array (that is, "[]"). I broke this in commit
6dcb7592e3 when adding support for
--output=threads|messages|tags. This time, while fixing the bug also
add a test to the test suite to help avoid future regressions.
Now that we understand the bug here, we rename this test to
search-insufficient-from-quoting to clarify the bug being exercised,
(which occurs when the From: line contains an unquoted '.' character).
We also mark these tests as expected failures until the bug gets fixed.
Currently, there are two places in the test framework that contain very
long list on a single line. Whenever a test is added (or changed) in
several branches and these branches are merged, it results in conflict
which is hard to resolve because one has to go through the whole long
line to find where the conflict is.
This patch splits these long lists to several lines so that the
conflicts are easier to resolve.
Currently, whenever we call index_terms multiple times for a single
field, the term generator is being reset to position 0 each time. This
means that with text such as:
To: a@b.c, x@y.z
one can get a bogus match by searching for:
To: a@y.c
Thanks to Mark Anderson for reporting the bug, (and providing a nice,
minimal test case that inspired what is used here).
This is a new feature which is not implemente yet, so these tests mostly
fail currently. A subsequent commit will add the feature and cause these
tests to start passing.
These tests verify that we can search for containing folders of mail files
by word or by phrase and that the search terms are updated correctly when
directories are renamed.
This reverts commit f22a7ec1e2.
Interrupting the test suite due to an actual bug in a test script
would be just fine, but interrupting the run of the entire test suite
at the first test failure is unacceptable.
Previously, this directory was only preserved for failing tests. But
it's important to be able to easily debug known-broken tests, so
preserve the actual vs. expected output for those as well.
Use varying dates in the test messages to test the order authors are
listed in. Add tests with repeated author names and unusual date
ordering. Most of these are broken at the moment, but will be fixed
shortly.
Edited-by: Carl Worth <cworth@cworth.org>: Also update the expected
results for existing emacs tests that currently codify the incorrect
author ordering, (and similarly note them as broken in the current
test suite).
Incremental search does not match strings that span a
visible/invisible boundary. This results in failure to correctly
isearch for authors in `notmuch-search' mode if the name of the author
is split between the visible and invisible components of the authors
string. To avoid this, attempt to truncate the visible component of
the authors string on a boundary between authors, such that the
entirety of an author's name is either visible or invisible.
When a test fails, a tmp.<testname> file is left behind. These files
are useful for the person debugging the test failure, but are never
anything we want to commit.
Edited-by: Carl Worth <cworth@cworth.org>: Changed from tmp.emacs to
tmp.* and added explanation in the commit message.
This testing *does* capture the bug of missing '[' and ']' characters
int "notmuch search --output=tags" case. This is another manifestation
of the same bug causing the missing final newline (as mentioned in the
previous commit).
This code simply wasn't being exercised by the test suite before, so
this will be useful.
Meanwhile, there's currently a bug in "notmuch search --output=tags"
in that it doesn't print a final newline. But the current test suite
isn't able to catch this bug since the $() construct of the shell
doesn't preserve the distinction of whether the final newline is
present or not.
This test script does some initial test setup (generating a few
messages), which is all well and good, but we don't need to print that
as a test result---particularly since the test result was effectively
hard-coded to always pass.
When test_begin_subtest is not followed by corresponding test_expect_equal,
the output of the rest of the test script is errornously suppressed. Add
code to detect these bugs in test scripts.
Break notmuch-test whenever a test script returns non-zero status.
This happens either when some test from the script fails or when there
is an error in the script.
This is especially useful in the latter case since the error may not
appear in the final aggregated results.
The newline was removed from say_color in commit 222926ab to allow
printing test status in the beginning of the line. Error messages are
never followed by other text so we add the newline to error function.
Git-style tests (test_expect_success etc.) suppress stdout and stderr
unless -v is given. Notmuch-style tests (created by test_begin_subtest
and test_expect_equal) do not have this behavior so implement it the
same.
Additionally, for both test styles, the test-lib.sh is changed so that
the content of suppressed stdout and stderr is shown in case of failed
test.
Finally a test for this functionality is added to basic tests.
This is to prevent notmuch from destroying any information the user
has encoded as flags in the maildir filename. Tests are also added to
the test suite to verify the documented behavior.
Some people use notmuch with non-maildir files, (for example, email
messages in MH format, or else cool things like using sluk[*] to suck
down feeds into a format that notmuch can index).
To better support uses like that, don't do any renaming for files that
are not in a directory named either "new" or "cur".
[*] https://github.com/krl/sluk/
The FCC code saves a message in maildir format, and sets the S flag by
default, so now, automatically, FCC messages will not show up as
"unread", (which seems natural enough).
There's nothing in the current API documentation that would suggest
the behavior being tested here. Attempt to implement this could have
some nasty side effects, (such as notmuch_message_maildir_flags_to_tags
implicitly calling notmuch_message_tags_to_maildir_flags and maybe
even opening up some bad looping possibilities).
Much better to stick with what we have documented, which we believe will
actually be useful, (and easy enough to comprehend).
