debian/notmuch
1
0
Fork 0
mirror of https://git.notmuchmail.org/git/notmuch synced 2024-12-27 11:51:42 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
notmuch/test/multipart

402 lines
14 KiB
Text
Raw Normal View History

Update some more recent tests to use /usr/bin/env to find bash The recentl-applied patch had grown stale, so update the tests that had been created since it was originally written.
2011-05-27 23:08:04 +02:00
#!/usr/bin/env bash
test: Add a test of "notmuch show" with a multipart message 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).
2011-05-17 00:25:25 +02:00
test_description="output of multipart message"
. ./test-lib.sh
cat <<EOF > ${MAIL_DIR}/multipart
From: Carl Worth <cworth@cworth.org>
To: cworth@cworth.org
Subject: Multipart message
test: Fix date in test message in multipart test. The test message date, "Tue, 05 Jan 2001 15:43:57 -0000", is not actually a real date. 05 Jan 2001 was in fact a Friday, not a Tuesday. Date parsers (such as "date" in coreutils) will return "Fri" as the day for this string, even if "Tue" is specified. Also, the time zone "-0000" is actually always returned as "+0000", so we change that here was well. This will be relevant for later patches when we begin parsing rfc822 part headers, where gmime returns a parsed date string. If we do want to test date parsing, we should do that in a separate test.
2011-06-06 02:29:26 +02:00
Date: Fri, 05 Jan 2001 15:43:57 +0000
test: Add a test of "notmuch show" with a multipart message 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).
2011-05-17 00:25:25 +02:00
User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1 (i486-pc-linux-gnu)
Message-ID: <87liy5ap00.fsf@yoom.home.cworth.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="==-=-=";
micalg=pgp-sha1; protocol="application/pgp-signature"
--==-=-=
Content-Type: multipart/mixed; boundary="=-=-="
--=-=-=
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
Content-Type: message/rfc822
Content-Disposition: inline
test: Add a test of "notmuch show" with a multipart message 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).
2011-05-17 00:25:25 +02:00
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
From: Carl Worth <cworth@cworth.org>
To: cworth@cworth.org
Subject: html message
test: Fix date in test message in multipart test. The test message date, "Tue, 05 Jan 2001 15:43:57 -0000", is not actually a real date. 05 Jan 2001 was in fact a Friday, not a Tuesday. Date parsers (such as "date" in coreutils) will return "Fri" as the day for this string, even if "Tue" is specified. Also, the time zone "-0000" is actually always returned as "+0000", so we change that here was well. This will be relevant for later patches when we begin parsing rfc822 part headers, where gmime returns a parsed date string. If we do want to test date parsing, we should do that in a separate test.
2011-06-06 02:29:26 +02:00
Date: Fri, 05 Jan 2001 15:42:57 +0000
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1 (i486-pc-linux-gnu)
Message-ID: <87liy5ap01.fsf@yoom.home.cworth.org>
MIME-Version: 1.0
Content-Type: text/html
test: Fix a misspelling in one of our test cases. 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.
2011-06-01 00:19:12 +02:00
<p>This is an embedded message, with a single html part.</p>
test: Add a test of "notmuch show" with a multipart message 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).
2011-05-17 00:25:25 +02:00
--=-=-=
Content-Disposition: attachment; filename=attachment
This is a text attachment.
--=-=-=
And this message is signed.
-Carl
--=-=-=--
--==-=-=
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk3SA/gACgkQ6JDdNq8qSWj0sACghqVJEQJUs3yV8zbTzhgnSIcD
W6cAmQE4dcYrx/LPLtYLZm1jsGauE5hE
=zkga
-----END PGP SIGNATURE-----
--==-=-=--
EOF
test: Add test showing notmuch corrupts a part with a CRLF pair in it Since commit 2f8871df6ea3c0b44f85a0fc1b4f58a6b70b0a0e 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.
2011-06-01 00:39:26 +02:00
cat <<EOF > ${MAIL_DIR}/base64-part-with-crlf
From: Carl Worth <cworth@cworth.org>
To: cworth@cworth.org
Subject: Test message with a BASE64 encoded binary containing CRLF pair
test: Fix date in test message in multipart test. The test message date, "Tue, 05 Jan 2001 15:43:57 -0000", is not actually a real date. 05 Jan 2001 was in fact a Friday, not a Tuesday. Date parsers (such as "date" in coreutils) will return "Fri" as the day for this string, even if "Tue" is specified. Also, the time zone "-0000" is actually always returned as "+0000", so we change that here was well. This will be relevant for later patches when we begin parsing rfc822 part headers, where gmime returns a parsed date string. If we do want to test date parsing, we should do that in a separate test.
2011-06-06 02:29:26 +02:00
Date: Fri, 05 Jan 2001 15:43:57 +0000
test: Add test showing notmuch corrupts a part with a CRLF pair in it Since commit 2f8871df6ea3c0b44f85a0fc1b4f58a6b70b0a0e 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.
2011-06-01 00:39:26 +02:00
User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1 (i486-pc-linux-gnu)
Message-ID: <base64-part-with-crlf>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==-=-=";
--==-=-=
The attached BASE64-encoded part expands to a binary containing a CRLF
pair (that is one bye of 0x0D followed by one byte of 0x0A). This is
designed to ensure that notmuch is not corrupting the output of this
part by converting the CRLF pair to an LF only (as would be appropriate
for display of a text part on a Linux system, for example).
The part should be a 3-byte file with the following sequence of 3
hexadecimal bytes:
EF 0D 0A
--==-=-=
Content-Type: application/octet-stream
Content-Disposition: attachment; filename=crlf.bin
Content-Transfer-Encoding: base64
7w0K
--==-=-=--
EOF
test: Add a test of "notmuch show" with a multipart message 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).
2011-05-17 00:25:25 +02:00
notmuch new > /dev/null
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
test_begin_subtest "--format=text --part=0, full message"
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
notmuch show --format=text --part=0 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
cat <<EOF >EXPECTED
message{ id:87liy5ap00.fsf@yoom.home.cworth.org depth:0 match:1 filename:${MAIL_DIR}/multipart
test: Add a test of "notmuch show" with a multipart message 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).
2011-05-17 00:25:25 +02:00
header{
tag signed/encrypted during notmuch new 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.
2011-05-26 03:01:20 +02:00
Carl Worth <cworth@cworth.org> (2001-01-05) (attachment inbox signed unread)
test: Add a test of "notmuch show" with a multipart message 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).
2011-05-17 00:25:25 +02:00
Subject: Multipart message
From: Carl Worth <cworth@cworth.org>
To: cworth@cworth.org
test: Fix date in test message in multipart test. The test message date, "Tue, 05 Jan 2001 15:43:57 -0000", is not actually a real date. 05 Jan 2001 was in fact a Friday, not a Tuesday. Date parsers (such as "date" in coreutils) will return "Fri" as the day for this string, even if "Tue" is specified. Also, the time zone "-0000" is actually always returned as "+0000", so we change that here was well. This will be relevant for later patches when we begin parsing rfc822 part headers, where gmime returns a parsed date string. If we do want to test date parsing, we should do that in a separate test.
2011-06-06 02:29:26 +02:00
Date: Fri, 05 Jan 2001 15:43:57 +0000
test: Add a test of "notmuch show" with a multipart message 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).
2011-05-17 00:25:25 +02:00
header}
body{
notmuch show: Include output for the enclosing multipart part of a MIME mail 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).
2011-05-17 07:28:36 +02:00
part{ ID: 1, Content-type: multipart/signed
part{ ID: 2, Content-type: multipart/mixed
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
part{ ID: 3, Content-type: message/rfc822
part{ ID: 4, Content-type: text/html
Non-text part: text/html
part}
test: Add a test of "notmuch show" with a multipart message 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).
2011-05-17 00:25:25 +02:00
part}
test: fix tests after notmuch show output changes related to filenames Adding the filename propery alongside ID and Content-type. This makes the test suite pass again after the recent change.
2011-05-29 00:03:48 +02:00
attachment{ ID: 5, Filename: attachment, Content-type: text/plain
test: Add a test of "notmuch show" with a multipart message 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).
2011-05-17 00:25:25 +02:00
This is a text attachment.
attachment}
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
part{ ID: 6, Content-type: text/plain
test: Add a test of "notmuch show" with a multipart message 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).
2011-05-17 00:25:25 +02:00
And this message is signed.
-Carl
part}
notmuch show: Properly nest MIME parts within mulipart parts 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.
2011-05-18 00:34:57 +02:00
part}
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
part{ ID: 7, Content-type: application/pgp-signature
test: Add a test of "notmuch show" with a multipart message 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).
2011-05-17 00:25:25 +02:00
Non-text part: application/pgp-signature
part}
notmuch show: Properly nest MIME parts within mulipart parts 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.
2011-05-18 00:34:57 +02:00
part}
test: Add a test of "notmuch show" with a multipart message 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).
2011-05-17 00:25:25 +02:00
body}
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
message}
EOF
test_expect_equal_file OUTPUT EXPECTED
test: Add a test of "notmuch show" with a multipart message 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).
2011-05-17 00:25:25 +02:00
test: some small fixes to multipart test There were two "--format=text --part=0" tests. One of them was supposed to be a test for "--format=text --part=1". There were also two errant "test_expect_equal_file OUTPUT EXPECTED" lines, that are removed here.
2011-06-06 02:29:25 +02:00
test_begin_subtest "--format=text --part=1, message body"
notmuch show --format=text --part=1 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
cat <<EOF >EXPECTED
part{ ID: 1, Content-type: multipart/signed
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
part{ ID: 2, Content-type: multipart/mixed
part{ ID: 3, Content-type: message/rfc822
part{ ID: 4, Content-type: text/html
Non-text part: text/html
part}
part}
test: fix tests after notmuch show output changes related to filenames Adding the filename propery alongside ID and Content-type. This makes the test suite pass again after the recent change.
2011-05-29 00:03:48 +02:00
attachment{ ID: 5, Filename: attachment, Content-type: text/plain
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
This is a text attachment.
attachment}
part{ ID: 6, Content-type: text/plain
And this message is signed.
test: Add a test of "notmuch show" with a multipart message 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).
2011-05-17 00:25:25 +02:00
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
-Carl
part}
part}
part{ ID: 7, Content-type: application/pgp-signature
Non-text part: application/pgp-signature
part}
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
part}
EOF
test_expect_equal_file OUTPUT EXPECTED
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
test_begin_subtest "--format=text --part=2, multipart/mixed"
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
notmuch show --format=text --part=2 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
cat <<EOF >EXPECTED
part{ ID: 2, Content-type: multipart/mixed
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
part{ ID: 3, Content-type: message/rfc822
part{ ID: 4, Content-type: text/html
Non-text part: text/html
part}
part}
test: fix tests after notmuch show output changes related to filenames Adding the filename propery alongside ID and Content-type. This makes the test suite pass again after the recent change.
2011-05-29 00:03:48 +02:00
attachment{ ID: 5, Filename: attachment, Content-type: text/plain
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
This is a text attachment.
attachment}
part{ ID: 6, Content-type: text/plain
And this message is signed.
-Carl
part}
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
part}
EOF
test_expect_equal_file OUTPUT EXPECTED
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
test_begin_subtest "--format=text --part=3, rfc822 multipart"
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
notmuch show --format=text --part=3 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
cat <<EOF >EXPECTED
part{ ID: 3, Content-type: message/rfc822
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
part{ ID: 4, Content-type: text/html
Non-text part: text/html
part}
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
part}
EOF
test_expect_equal_file OUTPUT EXPECTED
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
test_begin_subtest "--format=text --part=4, html part"
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
notmuch show --format=text --part=4 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
cat <<EOF >EXPECTED
part{ ID: 4, Content-type: text/html
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
Non-text part: text/html
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
part}
EOF
test_expect_equal_file OUTPUT EXPECTED
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
fix sum moar typos [user-visible documentation in code] 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".
2011-06-20 22:14:21 +02:00
test_begin_subtest "--format=text --part=5, inline attachment"
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
notmuch show --format=text --part=5 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
cat <<EOF >EXPECTED
test: fix tests after notmuch show output changes related to filenames Adding the filename propery alongside ID and Content-type. This makes the test suite pass again after the recent change.
2011-05-29 00:03:48 +02:00
attachment{ ID: 5, Filename: attachment, Content-type: text/plain
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
This is a text attachment.
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
attachment}
EOF
test_expect_equal_file OUTPUT EXPECTED
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
test_begin_subtest "--format=text --part=6, plain text part"
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
notmuch show --format=text --part=6 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
cat <<EOF >EXPECTED
part{ ID: 6, Content-type: text/plain
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
And this message is signed.
-Carl
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
part}
EOF
test_expect_equal_file OUTPUT EXPECTED
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
test_begin_subtest "--format=text --part=7, pgp signature (unverified)"
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
notmuch show --format=text --part=7 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
cat <<EOF >EXPECTED
part{ ID: 7, Content-type: application/pgp-signature
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
Non-text part: application/pgp-signature
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
part}
EOF
test_expect_equal_file OUTPUT EXPECTED
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
test_expect_success \
"--format=text --part=8, no part, expect error" \
"notmuch show --format=text --part=8 'id:87liy5ap00.fsf@yoom.home.cworth.org'"
test: Add a test of "notmuch show" with a multipart message 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).
2011-05-17 00:25:25 +02:00
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
test_begin_subtest "--format=json --part=0, full message"
output=$(notmuch show --format=json --part=0 'id:87liy5ap00.fsf@yoom.home.cworth.org')
test_expect_equal "$output" \
test: Fix date in test message in multipart test. The test message date, "Tue, 05 Jan 2001 15:43:57 -0000", is not actually a real date. 05 Jan 2001 was in fact a Friday, not a Tuesday. Date parsers (such as "date" in coreutils) will return "Fri" as the day for this string, even if "Tue" is specified. Also, the time zone "-0000" is actually always returned as "+0000", so we change that here was well. This will be relevant for later patches when we begin parsing rfc822 part headers, where gmime returns a parsed date string. If we do want to test date parsing, we should do that in a separate test.
2011-06-06 02:29:26 +02:00
'{"id": "87liy5ap00.fsf@yoom.home.cworth.org", "match": true, "filename": "'"${MAIL_DIR}/multipart"'", "timestamp": 978709437, "date_relative": "2001-01-05", "tags": ["attachment","inbox","signed","unread"], "headers": {"Subject": "Multipart message", "From": "Carl Worth <cworth@cworth.org>", "To": "cworth@cworth.org", "Cc": "", "Bcc": "", "Date": "Fri, 05 Jan 2001 15:43:57 +0000"}, "body": [{"id": 1, "content-type": "multipart/signed", "content": [{"id": 2, "content-type": "multipart/mixed", "content": [{"id": 3, "content-type": "message/rfc822", "content": [{"id": 4, "content-type": "text/html"}]}, {"id": 5, "content-type": "text/plain", "filename": "attachment", "content": "This is a text attachment.\n"}, {"id": 6, "content-type": "text/plain", "content": "And this message is signed.\n\n-Carl\n"}]}, {"id": 7, "content-type": "application/pgp-signature"}]}]}'
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
test_begin_subtest "--format=json --part=1, message body"
output=$(notmuch show --format=json --part=1 'id:87liy5ap00.fsf@yoom.home.cworth.org')
test_expect_equal "$output" \
'{"id": 1, "content-type": "multipart/signed", "content": [{"id": 2, "content-type": "multipart/mixed", "content": [{"id": 3, "content-type": "message/rfc822", "content": [{"id": 4, "content-type": "text/html"}]}, {"id": 5, "content-type": "text/plain", "filename": "attachment", "content": "This is a text attachment.\n"}, {"id": 6, "content-type": "text/plain", "content": "And this message is signed.\n\n-Carl\n"}]}, {"id": 7, "content-type": "application/pgp-signature"}]}'
test_begin_subtest "--format=json --part=2, multipart/mixed"
output=$(notmuch show --format=json --part=2 'id:87liy5ap00.fsf@yoom.home.cworth.org')
test_expect_equal "$output" \
'{"id": 2, "content-type": "multipart/mixed", "content": [{"id": 3, "content-type": "message/rfc822", "content": [{"id": 4, "content-type": "text/html"}]}, {"id": 5, "content-type": "text/plain", "filename": "attachment", "content": "This is a text attachment.\n"}, {"id": 6, "content-type": "text/plain", "content": "And this message is signed.\n\n-Carl\n"}]}'
test_begin_subtest "--format=json --part=3, rfc822 multipart"
output=$(notmuch show --format=json --part=3 'id:87liy5ap00.fsf@yoom.home.cworth.org')
test_expect_equal "$output" \
'{"id": 3, "content-type": "message/rfc822", "content": [{"id": 4, "content-type": "text/html"}]}'
test_begin_subtest "--format=json --part=4, html part"
output=$(notmuch show --format=json --part=4 'id:87liy5ap00.fsf@yoom.home.cworth.org')
test_expect_equal "$output" \
'{"id": 4, "content-type": "text/html"}'
test_begin_subtest "--format=json --part=5, inline attachment"
output=$(notmuch show --format=json --part=5 'id:87liy5ap00.fsf@yoom.home.cworth.org')
test_expect_equal "$output" \
'{"id": 5, "content-type": "text/plain", "filename": "attachment", "content": "This is a text attachment.\n"}'
test_begin_subtest "--format=json --part=6, plain text part"
output=$(notmuch show --format=json --part=6 'id:87liy5ap00.fsf@yoom.home.cworth.org')
test_expect_equal "$output" \
'{"id": 6, "content-type": "text/plain", "content": "And this message is signed.\n\n-Carl\n"}'
test_begin_subtest "--format=json --part=7, pgp signature (unverified)"
output=$(notmuch show --format=json --part=7 'id:87liy5ap00.fsf@yoom.home.cworth.org')
test_expect_equal "$output" \
'{"id": 7, "content-type": "application/pgp-signature"}'
test_expect_success \
"--format=json --part=8, no part, expect error" \
"notmuch show --format=json --part=8 'id:87liy5ap00.fsf@yoom.home.cworth.org'"
test_begin_subtest "--format=raw"
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
notmuch show --format=raw 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
test_expect_equal_file OUTPUT "${MAIL_DIR}"/multipart
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
test_begin_subtest "--format=raw --part=0, full message"
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
notmuch show --format=raw --part=0 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
test_expect_equal_file OUTPUT "${MAIL_DIR}"/multipart
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
test_begin_subtest "--format=raw --part=1, message body"
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
notmuch show --format=raw --part=1 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
# output should *not* include newline
echo >>OUTPUT
cat <<EOF >EXPECTED
<p>This is an embedded message, with a single html part.</p>
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
This is a text attachment.
And this message is signed.
-Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk3SA/gACgkQ6JDdNq8qSWj0sACghqVJEQJUs3yV8zbTzhgnSIcD
W6cAmQE4dcYrx/LPLtYLZm1jsGauE5hE
=zkga
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
-----END PGP SIGNATURE-----
EOF
test_expect_equal_file OUTPUT EXPECTED
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
test_begin_subtest "--format=raw --part=2, multipart/mixed"
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
notmuch show --format=raw --part=2 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
cat <<EOF >EXPECTED
<p>This is an embedded message, with a single html part.</p>
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
This is a text attachment.
And this message is signed.
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
-Carl
EOF
test_expect_equal_file OUTPUT EXPECTED
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
test_begin_subtest "--format=raw --part=3, rfc822 multipart"
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
notmuch show --format=raw --part=3 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
cat <<EOF >EXPECTED
<p>This is an embedded message, with a single html part.</p>
EOF
test_expect_equal_file OUTPUT EXPECTED
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
test_begin_subtest "--format=raw --part=4, html part"
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
notmuch show --format=raw --part=4 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
cat <<EOF >EXPECTED
<p>This is an embedded message, with a single html part.</p>
EOF
test_expect_equal_file OUTPUT EXPECTED
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
test_begin_subtest "--format=raw --part=5, inline attachment"
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
notmuch show --format=raw --part=5 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
cat <<EOF >EXPECTED
This is a text attachment.
EOF
test_expect_equal_file OUTPUT EXPECTED
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
test_begin_subtest "--format=raw --part=6, plain text part"
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
notmuch show --format=raw --part=6 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
cat <<EOF >EXPECTED
And this message is signed.
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
-Carl
EOF
test_expect_equal_file OUTPUT EXPECTED
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
test_begin_subtest "--format=raw --part=7, pgp signature (unverified)"
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
notmuch show --format=raw --part=7 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
# output should *not* include newline
echo >>OUTPUT
cat <<EOF >EXPECTED
-----BEGIN PGP SIGNATURE-----
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk3SA/gACgkQ6JDdNq8qSWj0sACghqVJEQJUs3yV8zbTzhgnSIcD
W6cAmQE4dcYrx/LPLtYLZm1jsGauE5hE
=zkga
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
-----END PGP SIGNATURE-----
EOF
test_expect_equal_file OUTPUT EXPECTED
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
test_expect_success \
"--format=raw --part=8, no part, expect error" \
"notmuch show --format=raw --part=8 'id:87liy5ap00.fsf@yoom.home.cworth.org'"
test_begin_subtest "--format=mbox"
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
notmuch show --format=mbox 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
printf "From cworth@cworth.org Fri Jan 5 15:43:57 2001\n" >EXPECTED
cat "${MAIL_DIR}"/multipart >>EXPECTED
# mbox output is expected to include a blank line
echo >>EXPECTED
test_expect_equal_file OUTPUT EXPECTED
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
test_expect_success \
"--format=mbox --part=1, incompatible, expect error" \
"! notmuch show --format=mbox --part=1 'id:87liy5ap00.fsf@yoom.home.cworth.org'"
test: Expand multipart test to cover "notmuch reply" as well This gives coverage for the segmentation fault in "notmuch reply" that was just fixed with the previous commit.
2011-05-24 19:56:38 +02:00
test_begin_subtest "'notmuch reply' to a multipart message"
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
notmuch reply 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
cat <<EOF >EXPECTED
From: Notmuch Test Suite <test_suite@notmuchmail.org>
test: Expand multipart test to cover "notmuch reply" as well This gives coverage for the segmentation fault in "notmuch reply" that was just fixed with the previous commit.
2011-05-24 19:56:38 +02:00
Subject: Re: Multipart message
To: Carl Worth <cworth@cworth.org>, cworth@cworth.org
In-Reply-To: <87liy5ap00.fsf@yoom.home.cworth.org>
References: <87liy5ap00.fsf@yoom.home.cworth.org>
test: Fix date in test message in multipart test. The test message date, "Tue, 05 Jan 2001 15:43:57 -0000", is not actually a real date. 05 Jan 2001 was in fact a Friday, not a Tuesday. Date parsers (such as "date" in coreutils) will return "Fri" as the day for this string, even if "Tue" is specified. Also, the time zone "-0000" is actually always returned as "+0000", so we change that here was well. This will be relevant for later patches when we begin parsing rfc822 part headers, where gmime returns a parsed date string. If we do want to test date parsing, we should do that in a separate test.
2011-06-06 02:29:26 +02:00
On Fri, 05 Jan 2001 15:43:57 +0000, Carl Worth <cworth@cworth.org> wrote:
test: Expand multipart test to cover "notmuch reply" as well This gives coverage for the segmentation fault in "notmuch reply" that was just fixed with the previous commit.
2011-05-24 19:56:38 +02:00
Non-text part: multipart/signed
Non-text part: multipart/mixed
Non-text part: message/rfc822
Non-text part: text/html
> This is a text attachment.
> And this message is signed.
>
> -Carl
test: modify multipart test to use test_expect_equal_file 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.
2011-05-28 23:16:30 +02:00
Non-text part: application/pgp-signature
EOF
test_expect_equal_file OUTPUT EXPECTED
test: Expand multipart test to cover "notmuch reply" as well This gives coverage for the segmentation fault in "notmuch reply" that was just fixed with the previous commit.
2011-05-24 19:56:38 +02:00
test: Add test showing notmuch corrupts a part with a CRLF pair in it Since commit 2f8871df6ea3c0b44f85a0fc1b4f58a6b70b0a0e 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.
2011-06-01 00:39:26 +02:00
test_begin_subtest "'notmuch show --part' does not corrupt a part with CRLF pair"
notmuch show --format=raw --part=3 id:base64-part-with-crlf > crlf.out
echo -n -e "\xEF\x0D\x0A" > crlf.expected
test_expect_equal_file crlf.out crlf.expected
test: Expand multipart test to cover "notmuch reply" as well This gives coverage for the segmentation fault in "notmuch reply" that was just fixed with the previous commit.
2011-05-24 19:56:38 +02:00
test: Expand multipart test to cover part output in all formats. 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.
2011-05-23 09:46:44 +02:00
test_done
Reference in a new issue Copy permalink