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

673 lines
23 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
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
cat <<EOF > embedded_message
From: Carl Worth <cworth@cworth.org>
To: cworth@cworth.org
Subject: html message
Date: Fri, 05 Jan 2001 15:42:57 +0000
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: multipart/alternative; boundary="==-=-=="
--==-=-==
Content-Type: text/html
<p>This is an embedded message, with a multipart/alternative part.</p>
--==-=-==
Content-Type: text/plain
This is an embedded message, with a multipart/alternative part.
--==-=-==--
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
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: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
EOF
cat embedded_message >> ${MAIL_DIR}/multipart
cat <<EOF >> ${MAIL_DIR}/multipart
test: Fix malformed multipart message Previously, there was only one CRLF between the terminating boundary of the embedded multipart/alternative and the boundary of the containing multipart. However, according the RFC 1341, 7.2.1: The boundary must be followed immediately either by another CRLF and the header fields for the next part, or by two CRLFs, in which case there are no header fields for the next part and The CRLF preceding the encapsulation line is considered part of the boundary so that it is possible to have a part that does not end with a CRLF (line break). Thus, there must be *two* CRLFs between these boundaries: one that ends the terminating boundary and one that begins the enclosing boundary. While GMime accepted the message we had before, it could not produce such a message.
2012-03-06 19:48:38 +01:00
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
test: update tests to reflect the exclude flag notmuch show outputs the exclude flag so many tests using notmuch show failed. This commit adds "excluded:0" or "excluded: false" to the expected outputs. After this commit there should be no failing tests.
2012-03-01 23:30:41 +01:00
message{ id:87liy5ap00.fsf@yoom.home.cworth.org depth:0 match:1 excluded:0 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
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
header{
show: Use consistent header ordering in the text format Previously, top-level message headers were printed as Subject, From, To, Date, while embedded message headers were printed From, To, Subject, Date. This makes both cases use the former order and updates the tests accordingly. Strangely, the raw format also uses this function, so this also fixes the two raw format tests affected by this change.
2012-01-23 03:31:12 +01:00
Subject: html message
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
From: Carl Worth <cworth@cworth.org>
To: cworth@cworth.org
Date: Fri, 05 Jan 2001 15:42:57 +0000
header}
body{
part{ ID: 4, Content-type: multipart/alternative
part{ ID: 5, 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
part}
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
part{ ID: 6, Content-type: text/plain
This is an embedded message, with a multipart/alternative part.
part}
part}
body}
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: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
attachment{ ID: 7, 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: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
part{ ID: 8, 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: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
part{ ID: 9, 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
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
header{
show: Use consistent header ordering in the text format Previously, top-level message headers were printed as Subject, From, To, Date, while embedded message headers were printed From, To, Subject, Date. This makes both cases use the former order and updates the tests accordingly. Strangely, the raw format also uses this function, so this also fixes the two raw format tests affected by this change.
2012-01-23 03:31:12 +01:00
Subject: html message
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
From: Carl Worth <cworth@cworth.org>
To: cworth@cworth.org
Date: Fri, 05 Jan 2001 15:42:57 +0000
header}
body{
part{ ID: 4, Content-type: multipart/alternative
part{ ID: 5, 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
part}
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
part{ ID: 6, Content-type: text/plain
This is an embedded message, with a multipart/alternative part.
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}
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
body}
part}
attachment{ ID: 7, 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}
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
part{ ID: 8, 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.
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}
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
part{ ID: 9, 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
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
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
header{
show: Use consistent header ordering in the text format Previously, top-level message headers were printed as Subject, From, To, Date, while embedded message headers were printed From, To, Subject, Date. This makes both cases use the former order and updates the tests accordingly. Strangely, the raw format also uses this function, so this also fixes the two raw format tests affected by this change.
2012-01-23 03:31:12 +01:00
Subject: html message
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
From: Carl Worth <cworth@cworth.org>
To: cworth@cworth.org
Date: Fri, 05 Jan 2001 15:42:57 +0000
header}
body{
part{ ID: 4, Content-type: multipart/alternative
part{ ID: 5, 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
part}
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
part{ ID: 6, Content-type: text/plain
This is an embedded message, with a multipart/alternative part.
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}
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
body}
part}
attachment{ ID: 7, 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}
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
part{ ID: 8, 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
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: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
test_begin_subtest "--format=text --part=3, rfc822 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=3 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
cat <<EOF >EXPECTED
part{ ID: 3, Content-type: message/rfc822
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
header{
show: Use consistent header ordering in the text format Previously, top-level message headers were printed as Subject, From, To, Date, while embedded message headers were printed From, To, Subject, Date. This makes both cases use the former order and updates the tests accordingly. Strangely, the raw format also uses this function, so this also fixes the two raw format tests affected by this change.
2012-01-23 03:31:12 +01:00
Subject: html message
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
From: Carl Worth <cworth@cworth.org>
To: cworth@cworth.org
Date: Fri, 05 Jan 2001 15:42:57 +0000
header}
body{
part{ ID: 4, Content-type: multipart/alternative
part{ ID: 5, 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
part}
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
part{ ID: 6, Content-type: text/plain
This is an embedded message, with a multipart/alternative part.
part}
part}
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
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: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
test_begin_subtest "--format=text --part=4, rfc822's 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=4 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
cat <<EOF >EXPECTED
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
part{ ID: 4, Content-type: multipart/alternative
part{ ID: 5, 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}
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
part{ ID: 6, Content-type: text/plain
This is an embedded message, with a multipart/alternative part.
part}
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
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: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
test_begin_subtest "--format=text --part=5, rfc822's 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=5 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
cat <<EOF >EXPECTED
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
part{ ID: 5, 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
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: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
test_begin_subtest "--format=text --part=6, rfc822's 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: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
This is an embedded message, with a multipart/alternative part.
part}
EOF
test_expect_equal_file OUTPUT EXPECTED
test_begin_subtest "--format=text --part=7, inline attachement"
notmuch show --format=text --part=7 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
cat <<EOF >EXPECTED
attachment{ ID: 7, Filename: attachment, Content-type: text/plain
This is a text attachment.
attachment}
EOF
test_expect_equal_file OUTPUT EXPECTED
test_begin_subtest "--format=text --part=8, plain text part"
notmuch show --format=text --part=8 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
cat <<EOF >EXPECTED
part{ ID: 8, 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: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
test_begin_subtest "--format=text --part=9, pgp signature (unverified)"
notmuch show --format=text --part=9 '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
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
part{ ID: 9, 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"
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
notmuch show --format=json --part=0 'id:87liy5ap00.fsf@yoom.home.cworth.org' | sed 's|{"id":|\n{"id":|g' >OUTPUT
echo >>OUTPUT # expect *no* newline at end of output
cat <<EOF >EXPECTED
test: update tests to reflect the exclude flag notmuch show outputs the exclude flag so many tests using notmuch show failed. This commit adds "excluded:0" or "excluded: false" to the expected outputs. After this commit there should be no failing tests.
2012-03-01 23:30:41 +01:00
{"id": "87liy5ap00.fsf@yoom.home.cworth.org", "match": true, "excluded": false, "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", "Date": "Fri, 05 Jan 2001 15:43:57 +0000"}, "body": [
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
{"id": 1, "content-type": "multipart/signed", "content": [
{"id": 2, "content-type": "multipart/mixed", "content": [
show: Use consistent header ordering in the JSON format Previously, top-level message headers were printed as Subject, From, To, Date, while embedded message headers were printed From, To, Subject, Date. This makes both cases use the former order and updates the tests accordingly.
2012-02-20 01:26:25 +01:00
{"id": 3, "content-type": "message/rfc822", "content": [{"headers": {"Subject": "html message", "From": "Carl Worth <cworth@cworth.org>", "To": "cworth@cworth.org", "Date": "Fri, 05 Jan 2001 15:42:57 +0000"}, "body": [
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
{"id": 4, "content-type": "multipart/alternative", "content": [
{"id": 5, "content-type": "text/html"},
{"id": 6, "content-type": "text/plain", "content": "This is an embedded message, with a multipart/alternative part.\n"}]}]}]},
{"id": 7, "content-type": "text/plain", "filename": "attachment", "content": "This is a text attachment.\n"},
{"id": 8, "content-type": "text/plain", "content": "And this message is signed.\n\n-Carl\n"}]},
{"id": 9, "content-type": "application/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=json --part=1, message body"
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
notmuch show --format=json --part=1 'id:87liy5ap00.fsf@yoom.home.cworth.org' | sed 's|{"id":|\n{"id":|g' >OUTPUT
echo >>OUTPUT # expect *no* newline at end of output
cat <<EOF >EXPECTED
{"id": 1, "content-type": "multipart/signed", "content": [
{"id": 2, "content-type": "multipart/mixed", "content": [
show: Use consistent header ordering in the JSON format Previously, top-level message headers were printed as Subject, From, To, Date, while embedded message headers were printed From, To, Subject, Date. This makes both cases use the former order and updates the tests accordingly.
2012-02-20 01:26:25 +01:00
{"id": 3, "content-type": "message/rfc822", "content": [{"headers": {"Subject": "html message", "From": "Carl Worth <cworth@cworth.org>", "To": "cworth@cworth.org", "Date": "Fri, 05 Jan 2001 15:42:57 +0000"}, "body": [
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
{"id": 4, "content-type": "multipart/alternative", "content": [
{"id": 5, "content-type": "text/html"},
{"id": 6, "content-type": "text/plain", "content": "This is an embedded message, with a multipart/alternative part.\n"}]}]}]},
{"id": 7, "content-type": "text/plain", "filename": "attachment", "content": "This is a text attachment.\n"},
{"id": 8, "content-type": "text/plain", "content": "And this message is signed.\n\n-Carl\n"}]},
{"id": 9, "content-type": "application/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=json --part=2, multipart/mixed"
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
notmuch show --format=json --part=2 'id:87liy5ap00.fsf@yoom.home.cworth.org' | sed 's|{"id":|\n{"id":|g' >OUTPUT
echo >>OUTPUT # expect *no* newline at end of output
cat <<EOF >EXPECTED
{"id": 2, "content-type": "multipart/mixed", "content": [
show: Use consistent header ordering in the JSON format Previously, top-level message headers were printed as Subject, From, To, Date, while embedded message headers were printed From, To, Subject, Date. This makes both cases use the former order and updates the tests accordingly.
2012-02-20 01:26:25 +01:00
{"id": 3, "content-type": "message/rfc822", "content": [{"headers": {"Subject": "html message", "From": "Carl Worth <cworth@cworth.org>", "To": "cworth@cworth.org", "Date": "Fri, 05 Jan 2001 15:42:57 +0000"}, "body": [
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
{"id": 4, "content-type": "multipart/alternative", "content": [
{"id": 5, "content-type": "text/html"},
{"id": 6, "content-type": "text/plain", "content": "This is an embedded message, with a multipart/alternative part.\n"}]}]}]},
{"id": 7, "content-type": "text/plain", "filename": "attachment", "content": "This is a text attachment.\n"},
{"id": 8, "content-type": "text/plain", "content": "And this message is signed.\n\n-Carl\n"}]}
EOF
test_expect_equal_file OUTPUT EXPECTED
test_begin_subtest "--format=json --part=3, rfc822 part"
notmuch show --format=json --part=3 'id:87liy5ap00.fsf@yoom.home.cworth.org' | sed 's|{"id":|\n{"id":|g' >OUTPUT
echo >>OUTPUT # expect *no* newline at end of output
cat <<EOF >EXPECTED
show: Use consistent header ordering in the JSON format Previously, top-level message headers were printed as Subject, From, To, Date, while embedded message headers were printed From, To, Subject, Date. This makes both cases use the former order and updates the tests accordingly.
2012-02-20 01:26:25 +01:00
{"id": 3, "content-type": "message/rfc822", "content": [{"headers": {"Subject": "html message", "From": "Carl Worth <cworth@cworth.org>", "To": "cworth@cworth.org", "Date": "Fri, 05 Jan 2001 15:42:57 +0000"}, "body": [
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
{"id": 4, "content-type": "multipart/alternative", "content": [
{"id": 5, "content-type": "text/html"},
{"id": 6, "content-type": "text/plain", "content": "This is an embedded message, with a multipart/alternative part.\n"}]}]}]}
EOF
test_expect_equal_file OUTPUT EXPECTED
test_begin_subtest "--format=json --part=4, rfc822's multipart/alternative"
notmuch show --format=json --part=4 'id:87liy5ap00.fsf@yoom.home.cworth.org' | sed 's|{"id":|\n{"id":|g' >OUTPUT
echo >>OUTPUT # expect *no* newline at end of output
cat <<EOF >EXPECTED
{"id": 4, "content-type": "multipart/alternative", "content": [
{"id": 5, "content-type": "text/html"},
{"id": 6, "content-type": "text/plain", "content": "This is an embedded message, with a multipart/alternative part.\n"}]}
EOF
test_expect_equal_file OUTPUT EXPECTED
test_begin_subtest "--format=json --part=5, rfc822's html part"
notmuch show --format=json --part=5 'id:87liy5ap00.fsf@yoom.home.cworth.org' | sed 's|{"id":|\n{"id":|g' >OUTPUT
echo >>OUTPUT # expect *no* newline at end of output
cat <<EOF >EXPECTED
{"id": 5, "content-type": "text/html"}
EOF
test_expect_equal_file OUTPUT EXPECTED
test_begin_subtest "--format=json --part=6, rfc822's text part"
notmuch show --format=json --part=6 'id:87liy5ap00.fsf@yoom.home.cworth.org' | sed 's|{"id":|\n{"id":|g' >OUTPUT
echo >>OUTPUT # expect *no* newline at end of output
cat <<EOF >EXPECTED
{"id": 6, "content-type": "text/plain", "content": "This is an embedded message, with a multipart/alternative part.\n"}
EOF
test_expect_equal_file OUTPUT EXPECTED
test_begin_subtest "--format=json --part=7, inline attachment"
notmuch show --format=json --part=7 'id:87liy5ap00.fsf@yoom.home.cworth.org' | sed 's|{"id":|\n{"id":|g' >OUTPUT
echo >>OUTPUT # expect *no* newline at end of output
cat <<EOF >EXPECTED
{"id": 7, "content-type": "text/plain", "filename": "attachment", "content": "This is a text attachment.\n"}
EOF
test_expect_equal_file OUTPUT EXPECTED
test_begin_subtest "--format=json --part=8, plain text part"
notmuch show --format=json --part=8 'id:87liy5ap00.fsf@yoom.home.cworth.org' | sed 's|{"id":|\n{"id":|g' >OUTPUT
echo >>OUTPUT # expect *no* newline at end of output
cat <<EOF >EXPECTED
{"id": 8, "content-type": "text/plain", "content": "And this message is signed.\n\n-Carl\n"}
EOF
test_expect_equal_file OUTPUT EXPECTED
test_begin_subtest "--format=json --part=9, pgp signature (unverified)"
notmuch show --format=json --part=9 'id:87liy5ap00.fsf@yoom.home.cworth.org' | sed 's|{"id":|\n{"id":|g' >OUTPUT
echo >>OUTPUT # expect *no* newline at end of output
cat <<EOF >EXPECTED
{"id": 9, "content-type": "application/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 \
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
"--format=json --part=10, no part, expect error" \
"notmuch show --format=json --part=10 'id:87liy5ap00.fsf@yoom.home.cworth.org'"
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"
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
show: Convert raw format to the new self-recursive style, properly support interior parts This is fully compatible for root and leaf parts, but now has proper support for interior parts. This requires some design decisions that were guided by what I would want if I were to save a part. Specifically: - Leaf parts are printed without headers and with transfer decoding. This is what makes sense for saving attachments. (Furthermore, the transfer decoding is necessary since, without the headers, the caller would not be able to interpret non-transfer-decoded output.) - Message parts are printed with their message headers, but without enclosing part headers. This is what makes sense for saving a message as a whole (which is a message part) and for saving attached messages. This is symmetric for whole messages and for attached messages, though we special-case the whole message for performance reasons (and corner-case correctness reasons: given malformed input, GMime may not be able to reproduce it from the parsed representation). - Multipart parts are printed with their headers and all child parts. It's not clear what the best thing to do for multipart is, but this was the most natural to implement and can be justified because such parts can't be interpreted without their headers. As an added benefit, we can move the special-case code for part 0 into the raw formatter.
2012-03-06 19:48:43 +01:00
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=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
show: Convert raw format to the new self-recursive style, properly support interior parts This is fully compatible for root and leaf parts, but now has proper support for interior parts. This requires some design decisions that were guided by what I would want if I were to save a part. Specifically: - Leaf parts are printed without headers and with transfer decoding. This is what makes sense for saving attachments. (Furthermore, the transfer decoding is necessary since, without the headers, the caller would not be able to interpret non-transfer-decoded output.) - Message parts are printed with their message headers, but without enclosing part headers. This is what makes sense for saving a message as a whole (which is a message part) and for saving attached messages. This is symmetric for whole messages and for attached messages, though we special-case the whole message for performance reasons (and corner-case correctness reasons: given malformed input, GMime may not be able to reproduce it from the parsed representation). - Multipart parts are printed with their headers and all child parts. It's not clear what the best thing to do for multipart is, but this was the most natural to implement and can be justified because such parts can't be interpreted without their headers. As an added benefit, we can move the special-case code for part 0 into the raw formatter.
2012-03-06 19:48:43 +01:00
Content-Type: multipart/mixed; boundary="=-=-="
--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
From: Carl Worth <cworth@cworth.org>
To: cworth@cworth.org
show: Convert raw format to the new self-recursive style, properly support interior parts This is fully compatible for root and leaf parts, but now has proper support for interior parts. This requires some design decisions that were guided by what I would want if I were to save a part. Specifically: - Leaf parts are printed without headers and with transfer decoding. This is what makes sense for saving attachments. (Furthermore, the transfer decoding is necessary since, without the headers, the caller would not be able to interpret non-transfer-decoded output.) - Message parts are printed with their message headers, but without enclosing part headers. This is what makes sense for saving a message as a whole (which is a message part) and for saving attached messages. This is symmetric for whole messages and for attached messages, though we special-case the whole message for performance reasons (and corner-case correctness reasons: given malformed input, GMime may not be able to reproduce it from the parsed representation). - Multipart parts are printed with their headers and all child parts. It's not clear what the best thing to do for multipart is, but this was the most natural to implement and can be justified because such parts can't be interpreted without their headers. As an added benefit, we can move the special-case code for part 0 into the raw formatter.
2012-03-06 19:48:43 +01:00
Subject: html message
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
Date: Fri, 05 Jan 2001 15:42:57 +0000
show: Convert raw format to the new self-recursive style, properly support interior parts This is fully compatible for root and leaf parts, but now has proper support for interior parts. This requires some design decisions that were guided by what I would want if I were to save a part. Specifically: - Leaf parts are printed without headers and with transfer decoding. This is what makes sense for saving attachments. (Furthermore, the transfer decoding is necessary since, without the headers, the caller would not be able to interpret non-transfer-decoded output.) - Message parts are printed with their message headers, but without enclosing part headers. This is what makes sense for saving a message as a whole (which is a message part) and for saving attached messages. This is symmetric for whole messages and for attached messages, though we special-case the whole message for performance reasons (and corner-case correctness reasons: given malformed input, GMime may not be able to reproduce it from the parsed representation). - Multipart parts are printed with their headers and all child parts. It's not clear what the best thing to do for multipart is, but this was the most natural to implement and can be justified because such parts can't be interpreted without their headers. As an added benefit, we can move the special-case code for part 0 into the raw formatter.
2012-03-06 19:48:43 +01: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: multipart/alternative; boundary="==-=-=="
--==-=-==
Content-Type: text/html
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
<p>This is an embedded message, with a multipart/alternative part.</p>
show: Convert raw format to the new self-recursive style, properly support interior parts This is fully compatible for root and leaf parts, but now has proper support for interior parts. This requires some design decisions that were guided by what I would want if I were to save a part. Specifically: - Leaf parts are printed without headers and with transfer decoding. This is what makes sense for saving attachments. (Furthermore, the transfer decoding is necessary since, without the headers, the caller would not be able to interpret non-transfer-decoded output.) - Message parts are printed with their message headers, but without enclosing part headers. This is what makes sense for saving a message as a whole (which is a message part) and for saving attached messages. This is symmetric for whole messages and for attached messages, though we special-case the whole message for performance reasons (and corner-case correctness reasons: given malformed input, GMime may not be able to reproduce it from the parsed representation). - Multipart parts are printed with their headers and all child parts. It's not clear what the best thing to do for multipart is, but this was the most natural to implement and can be justified because such parts can't be interpreted without their headers. As an added benefit, we can move the special-case code for part 0 into the raw formatter.
2012-03-06 19:48:43 +01:00
--==-=-==
Content-Type: text/plain
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
This is an embedded message, with a multipart/alternative part.
show: Convert raw format to the new self-recursive style, properly support interior parts This is fully compatible for root and leaf parts, but now has proper support for interior parts. This requires some design decisions that were guided by what I would want if I were to save a part. Specifically: - Leaf parts are printed without headers and with transfer decoding. This is what makes sense for saving attachments. (Furthermore, the transfer decoding is necessary since, without the headers, the caller would not be able to interpret non-transfer-decoded output.) - Message parts are printed with their message headers, but without enclosing part headers. This is what makes sense for saving a message as a whole (which is a message part) and for saving attached messages. This is symmetric for whole messages and for attached messages, though we special-case the whole message for performance reasons (and corner-case correctness reasons: given malformed input, GMime may not be able to reproduce it from the parsed representation). - Multipart parts are printed with their headers and all child parts. It's not clear what the best thing to do for multipart is, but this was the most natural to implement and can be justified because such parts can't be interpreted without their headers. As an added benefit, we can move the special-case code for part 0 into the raw formatter.
2012-03-06 19:48:43 +01:00
--==-=-==--
--=-=-=
Content-Disposition: attachment; filename=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
This is a text attachment.
show: Convert raw format to the new self-recursive style, properly support interior parts This is fully compatible for root and leaf parts, but now has proper support for interior parts. This requires some design decisions that were guided by what I would want if I were to save a part. Specifically: - Leaf parts are printed without headers and with transfer decoding. This is what makes sense for saving attachments. (Furthermore, the transfer decoding is necessary since, without the headers, the caller would not be able to interpret non-transfer-decoded output.) - Message parts are printed with their message headers, but without enclosing part headers. This is what makes sense for saving a message as a whole (which is a message part) and for saving attached messages. This is symmetric for whole messages and for attached messages, though we special-case the whole message for performance reasons (and corner-case correctness reasons: given malformed input, GMime may not be able to reproduce it from the parsed representation). - Multipart parts are printed with their headers and all child parts. It's not clear what the best thing to do for multipart is, but this was the most natural to implement and can be justified because such parts can't be interpreted without their headers. As an added benefit, we can move the special-case code for part 0 into the raw formatter.
2012-03-06 19:48:43 +01: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
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
show: Convert raw format to the new self-recursive style, properly support interior parts This is fully compatible for root and leaf parts, but now has proper support for interior parts. This requires some design decisions that were guided by what I would want if I were to save a part. Specifically: - Leaf parts are printed without headers and with transfer decoding. This is what makes sense for saving attachments. (Furthermore, the transfer decoding is necessary since, without the headers, the caller would not be able to interpret non-transfer-decoded output.) - Message parts are printed with their message headers, but without enclosing part headers. This is what makes sense for saving a message as a whole (which is a message part) and for saving attached messages. This is symmetric for whole messages and for attached messages, though we special-case the whole message for performance reasons (and corner-case correctness reasons: given malformed input, GMime may not be able to reproduce it from the parsed representation). - Multipart parts are printed with their headers and all child parts. It's not clear what the best thing to do for multipart is, but this was the most natural to implement and can be justified because such parts can't be interpreted without their headers. As an added benefit, we can move the special-case code for part 0 into the raw formatter.
2012-03-06 19:48:43 +01: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
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: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
test_begin_subtest "--format=raw --part=3, rfc822 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=3 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
test_expect_equal_file OUTPUT embedded_message
test: Fix typo in test description Part 4 is a multipart, not an html part.
2012-03-06 19:48:37 +01:00
test_begin_subtest "--format=raw --part=4, rfc822's multipart"
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
notmuch show --format=raw --part=4 '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
show: Convert raw format to the new self-recursive style, properly support interior parts This is fully compatible for root and leaf parts, but now has proper support for interior parts. This requires some design decisions that were guided by what I would want if I were to save a part. Specifically: - Leaf parts are printed without headers and with transfer decoding. This is what makes sense for saving attachments. (Furthermore, the transfer decoding is necessary since, without the headers, the caller would not be able to interpret non-transfer-decoded output.) - Message parts are printed with their message headers, but without enclosing part headers. This is what makes sense for saving a message as a whole (which is a message part) and for saving attached messages. This is symmetric for whole messages and for attached messages, though we special-case the whole message for performance reasons (and corner-case correctness reasons: given malformed input, GMime may not be able to reproduce it from the parsed representation). - Multipart parts are printed with their headers and all child parts. It's not clear what the best thing to do for multipart is, but this was the most natural to implement and can be justified because such parts can't be interpreted without their headers. As an added benefit, we can move the special-case code for part 0 into the raw formatter.
2012-03-06 19:48:43 +01:00
From: Carl Worth <cworth@cworth.org>
To: cworth@cworth.org
Subject: html message
Date: Fri, 05 Jan 2001 15:42:57 +0000
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: multipart/alternative; boundary="==-=-=="
--==-=-==
Content-Type: text/html
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
<p>This is an embedded message, with a multipart/alternative part.</p>
show: Convert raw format to the new self-recursive style, properly support interior parts This is fully compatible for root and leaf parts, but now has proper support for interior parts. This requires some design decisions that were guided by what I would want if I were to save a part. Specifically: - Leaf parts are printed without headers and with transfer decoding. This is what makes sense for saving attachments. (Furthermore, the transfer decoding is necessary since, without the headers, the caller would not be able to interpret non-transfer-decoded output.) - Message parts are printed with their message headers, but without enclosing part headers. This is what makes sense for saving a message as a whole (which is a message part) and for saving attached messages. This is symmetric for whole messages and for attached messages, though we special-case the whole message for performance reasons (and corner-case correctness reasons: given malformed input, GMime may not be able to reproduce it from the parsed representation). - Multipart parts are printed with their headers and all child parts. It's not clear what the best thing to do for multipart is, but this was the most natural to implement and can be justified because such parts can't be interpreted without their headers. As an added benefit, we can move the special-case code for part 0 into the raw formatter.
2012-03-06 19:48:43 +01:00
--==-=-==
Content-Type: text/plain
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
This is an embedded message, with a multipart/alternative part.
show: Convert raw format to the new self-recursive style, properly support interior parts This is fully compatible for root and leaf parts, but now has proper support for interior parts. This requires some design decisions that were guided by what I would want if I were to save a part. Specifically: - Leaf parts are printed without headers and with transfer decoding. This is what makes sense for saving attachments. (Furthermore, the transfer decoding is necessary since, without the headers, the caller would not be able to interpret non-transfer-decoded output.) - Message parts are printed with their message headers, but without enclosing part headers. This is what makes sense for saving a message as a whole (which is a message part) and for saving attached messages. This is symmetric for whole messages and for attached messages, though we special-case the whole message for performance reasons (and corner-case correctness reasons: given malformed input, GMime may not be able to reproduce it from the parsed representation). - Multipart parts are printed with their headers and all child parts. It's not clear what the best thing to do for multipart is, but this was the most natural to implement and can be justified because such parts can't be interpreted without their headers. As an added benefit, we can move the special-case code for part 0 into the raw formatter.
2012-03-06 19:48:43 +01: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
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: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
test_begin_subtest "--format=raw --part=5, rfc822's html part"
notmuch show --format=raw --part=5 '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
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
<p>This is an embedded message, with a multipart/alternative part.</p>
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
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: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
test_begin_subtest "--format=raw --part=6, rfc822's text part"
notmuch show --format=raw --part=6 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
cat <<EOF >EXPECTED
This is an embedded message, with a multipart/alternative part.
EOF
test_expect_equal_file OUTPUT EXPECTED
test_begin_subtest "--format=raw --part=7, inline attachment"
notmuch show --format=raw --part=7 '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
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: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
test_begin_subtest "--format=raw --part=8, plain text part"
notmuch show --format=raw --part=8 '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
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: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
test_begin_subtest "--format=raw --part=9, pgp signature (unverified)"
notmuch show --format=raw --part=9 '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
# 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 \
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
"--format=raw --part=10, no part, expect error" \
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
"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: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
> From: Carl Worth <cworth@cworth.org>
> To: cworth@cworth.org
> Subject: html message
> Date: Fri, 05 Jan 2001 15:42:57 +0000
>
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: text/html
test: overhaul multipart test to test for improved message/rfc822 handling The main goal of this overhaul is to define how message/rfc822 parts should be handled. message/rfc822 parts should be output in a similar fashion to the outer message, including some subset of the rfc822 headers. The following decisions about formatting of message/rfc822 parts were made: The format and content of message/rfc822 parts shall be as similar as possible to that of full messages. In particular, for formatted outputs, the "content" of rfc822 part output should include "headers" and "body" fields). The "body" field shall include the body of the message. The "headers" field shall include the following headers, since these are the ones available from the GMimeMessage: "From" "To" "Cc" "Subject" "Date" However, for the case of --format=raw the raw rfc822 should be output, including all headers. A subset of relevant headers shall be output in reply. The test embedded rfc822 message is also modified to be itself multipart, so we can more fully test how all sub parts of the message part are output. Note added by Committer: Currently, expect one test (--format=raw --part=3, rfc822 part) to fail.
2011-09-05 21:01:46 +02:00
> This is an embedded message, with a multipart/alternative part.
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
> 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
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 broken test for the new JSON reply format.
2012-03-18 17:32:33 +01:00
test_begin_subtest "'notmuch reply' to a multipart message with json format"
test_subtest_known_broken
notmuch reply --format=json 'id:87liy5ap00.fsf@yoom.home.cworth.org' | notmuch_json_show_sanitize >OUTPUT
cat <<EOF >EXPECTED
{"reply-headers": {"Subject": "Re: Multipart message",
"From": "Notmuch Test Suite <test_suite@notmuchmail.org>",
"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>"},
"original": {"id": "XXXXX",
"match": false,
"excluded": false,
"filename": "YYYYY",
"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",
"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": [{"headers": {"Subject": "html message",
"From": "Carl Worth <cworth@cworth.org>",
"To": "cworth@cworth.org",
"Date": "Fri,
05 Jan 2001 15:42:57 +0000"},
"body": [{"id": 4,
"content-type": "multipart/alternative",
"content": [{"id": 5,
"content-type": "text/html"},
{"id": 6,
"content-type": "text/plain",
"content": "This is an embedded message,
with a multipart/alternative part.\n"}]}]}]},
{"id": 7,
"content-type": "text/plain",
"filename": "YYYYY",
"content": "This is a text attachment.\n"},
{"id": 8,
"content-type": "text/plain",
"content": "And this message is signed.\n\n-Carl\n"}]},
{"id": 9,
"content-type": "application/pgp-signature"}]}]}}
EOF
test_expect_equal_file OUTPUT EXPECTED
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: update tests to reflect the exclude flag notmuch show outputs the exclude flag so many tests using notmuch show failed. This commit adds "excluded:0" or "excluded: false" to the expected outputs. After this commit there should be no failing tests.
2012-03-01 23:30:41 +01:00
test_done
Reference in a new issue Copy permalink