debian/notmuch
1
0
Fork 0
mirror of https://git.notmuchmail.org/git/notmuch synced 2024-11-21 18:38:08 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
notmuch/test/T190-multipart.sh

834 lines
29 KiB
Bash
Raw Permalink 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: use $(dirname "$0") for sourcing test-lib.sh Don't assume the tests are always run from within the source tree.
2017-09-25 22:38:19 +02:00
. $(dirname "$0")/test-lib.sh || exit 1
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/multipart: reorganize creation of multipart message We want to have the bodies of the multipart available in a file on their own for planned modifications to tests.
2017-06-03 19:47:35 +02:00
cat <<EOF > embedded_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
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/multipart: reorganize creation of multipart message We want to have the bodies of the multipart available in a file on their own for planned modifications to tests.
2017-06-03 19:47:35 +02:00
cat <<EOF > embedded_message
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
From: Carl Worth <cworth@cworth.org>
To: cworth@cworth.org
test/multipart: reorganize creation of multipart message We want to have the bodies of the multipart available in a file on their own for planned modifications to tests.
2017-06-03 19:47:35 +02:00
Subject: html message
Date: Fri, 05 Jan 2001 15:42: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)
test/multipart: reorganize creation of multipart message We want to have the bodies of the multipart available in a file on their own for planned modifications to tests.
2017-06-03 19:47:35 +02:00
Message-ID: <87liy5ap01.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
MIME-Version: 1.0
test/multipart: reorganize creation of multipart message We want to have the bodies of the multipart available in a file on their own for planned modifications to tests.
2017-06-03 19:47:35 +02:00
EOF
cat embedded_message_body >> embedded_message
cat <<EOF > multipart_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
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
test/multipart: reorganize creation of multipart message We want to have the bodies of the multipart available in a file on their own for planned modifications to tests.
2017-06-03 19:47:35 +02:00
cat embedded_message >> multipart_body
cat <<EOF >> multipart_body
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
test/multipart: reorganize creation of multipart message We want to have the bodies of the multipart available in a file on their own for planned modifications to tests.
2017-06-03 19:47:35 +02:00
cat <<EOF > ${MAIL_DIR}/multipart
From: Carl Worth <cworth@cworth.org>
To: cworth@cworth.org
Subject: Multipart message
Date: Fri, 05 Jan 2001 15:43:57 +0000
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
EOF
cat multipart_body >> ${MAIL_DIR}/multipart
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 failing unit tests for indexed mime types Adds three failing unit tests for searching of mime-types. An attempt was made at adding a negative test (i.e. searching for a non-existent mime-type and ensuring it didn't return a message), but that test would always pass making it pointless.
2015-01-23 00:43:36 +01:00
cat <<EOF > content_types
From: Todd <todd@example.com>
To: todd@example.com
Subject: odd content types
Date: Mon, 12 Jan 2014 18:12:32 +0000
User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1 (i486-pc-linux-gnu)
Message-ID: <KfjfO2WJBw2hrV2p0gjT@example.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="==-=-=="
--==-=-==
Content-Type: application/unique_identifier
<p>This is an embedded message, with a multipart/alternative part.</p>
--==-=-==
Content-Type: text/some_other_identifier
This is an embedded message, with a multipart/alternative part.
--==-=-==--
EOF
cat content_types >> ${MAIL_DIR}/odd_content_type
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: standardize argument order to test_expect_equal_file It is annoying to debug failing tests when the interpretation of the diffs is reversed for some tests.
2017-04-05 02:36:29 +02:00
test_expect_equal_file EXPECTED OUTPUT
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
cli: notmuch show support for --body=false with --format=text
2018-10-31 00:54:31 +01:00
test_begin_subtest "--format=text --part=0 --body=false, message header"
notmuch show --format=text --part=0 --body=false 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
cat <<EOF >EXPECTED
message{ id:87liy5ap00.fsf@yoom.home.cworth.org depth:0 match:1 excluded:0 filename:${MAIL_DIR}/multipart
header{
Carl Worth <cworth@cworth.org> (2001-01-05) (attachment inbox signed unread)
Subject: Multipart message
From: Carl Worth <cworth@cworth.org>
To: cworth@cworth.org
Date: Fri, 05 Jan 2001 15:43:57 +0000
header}
message}
EOF
test_expect_equal_file EXPECTED OUTPUT
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: standardize argument order to test_expect_equal_file It is annoying to debug failing tests when the interpretation of the diffs is reversed for some tests.
2017-04-05 02:36:29 +02:00
test_expect_equal_file EXPECTED OUTPUT
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: standardize argument order to test_expect_equal_file It is annoying to debug failing tests when the interpretation of the diffs is reversed for some tests.
2017-04-05 02:36:29 +02:00
test_expect_equal_file EXPECTED OUTPUT
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: standardize argument order to test_expect_equal_file It is annoying to debug failing tests when the interpretation of the diffs is reversed for some tests.
2017-04-05 02:36:29 +02:00
test_expect_equal_file EXPECTED OUTPUT
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: standardize argument order to test_expect_equal_file It is annoying to debug failing tests when the interpretation of the diffs is reversed for some tests.
2017-04-05 02:36:29 +02:00
test_expect_equal_file EXPECTED OUTPUT
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: standardize argument order to test_expect_equal_file It is annoying to debug failing tests when the interpretation of the diffs is reversed for some tests.
2017-04-05 02:36:29 +02:00
test_expect_equal_file EXPECTED OUTPUT
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
cli: notmuch show support for --include-html with --format=text
2018-10-31 00:54:32 +01:00
test_begin_subtest "--format=text --include-html --part=5, rfc822's html part"
notmuch show --format=text --include-html --part=5 'id:87liy5ap00.fsf@yoom.home.cworth.org' >OUTPUT
cat <<EOF >EXPECTED
part{ ID: 5, Content-type: text/html
<p>This is an embedded message, with a multipart/alternative part.</p>
part}
EOF
test_expect_equal_file EXPECTED 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_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: standardize argument order to test_expect_equal_file It is annoying to debug failing tests when the interpretation of the diffs is reversed for some tests.
2017-04-05 02:36:29 +02:00
test_expect_equal_file EXPECTED 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
Fix typos as found by codespell Signed-off-by: Georg Faerber <georg@riseup.net>
2018-03-18 03:30:25 +01:00
test_begin_subtest "--format=text --part=7, inline 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
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: standardize argument order to test_expect_equal_file It is annoying to debug failing tests when the interpretation of the diffs is reversed for some tests.
2017-04-05 02:36:29 +02:00
test_expect_equal_file EXPECTED 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_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: standardize argument order to test_expect_equal_file It is annoying to debug failing tests when the interpretation of the diffs is reversed for some tests.
2017-04-05 02:36:29 +02:00
test_expect_equal_file EXPECTED OUTPUT
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: standardize argument order to test_expect_equal_file It is annoying to debug failing tests when the interpretation of the diffs is reversed for some tests.
2017-04-05 02:36:29 +02:00
test_expect_equal_file EXPECTED OUTPUT
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: require test_begin_subtest before test_expect_success Unify the subtests by requiring test_begin_subtest before test_expect_success. (Similar change for test_expect_code will follow.) This increases clarity in the test scripts by having a separate line for the start of the subtest with the heading, and makes it possible to simplify the test infrastructure by making all subtests similar.
2017-02-26 14:43:00 +01:00
test_begin_subtest "--format=text --part=8, no part, expect error"
test_expect_success "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: use notmuch_json_show_sanitize more places This makes the tests more robust against changing output formats, by allowing us to centralize fixes in the sanitization function. It is not appropriate for all cases, in particular it is unneeded when using test_json_nodes, and unhelpful when testing filenames.
2022-07-01 23:45:40 +02:00
notmuch show --format=json --part=0 'id:87liy5ap00.fsf@yoom.home.cworth.org' | notmuch_json_show_sanitize >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
cat <<EOF >EXPECTED
test: use notmuch_json_show_sanitize more places This makes the tests more robust against changing output formats, by allowing us to centralize fixes in the sanitization function. It is not appropriate for all cases, in particular it is unneeded when using test_json_nodes, and unhelpful when testing filenames.
2022-07-01 23:45:40 +02:00
{"id": "XXXXX", "crypto": {}, "match": true, "excluded": false, "filename": ["YYYYY"], "timestamp": 42, "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": "GENERATED_DATE"}, "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": [
test: use notmuch_json_show_sanitize more places This makes the tests more robust against changing output formats, by allowing us to centralize fixes in the sanitization function. It is not appropriate for all cases, in particular it is unneeded when using test_json_nodes, and unhelpful when testing filenames.
2022-07-01 23:45:40 +02:00
{"id": 3, "content-type": "message/rfc822", "content-disposition": "inline", "content": [{"headers": {"Subject": "html message", "From": "Carl Worth <cworth@cworth.org>", "To": "cworth@cworth.org", "Date": "GENERATED_DATE"}, "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": [
test: use notmuch_json_show_sanitize more places This makes the tests more robust against changing output formats, by allowing us to centralize fixes in the sanitization function. It is not appropriate for all cases, in particular it is unneeded when using test_json_nodes, and unhelpful when testing filenames.
2022-07-01 23:45:40 +02:00
{"id": 5, "content-type": "text/html", "content-length": "NONZERO"},
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": 6, "content-type": "text/plain", "content": "This is an embedded message, with a multipart/alternative part.\n"}]}]}]},
cli/show: add content-disposition to structured output message parts Help the clients decide how to display parts. Test updates by Mark Walters <markwalters1009@gmail.com>. One more test fix by db
2017-02-26 19:33:48 +01:00
{"id": 7, "content-type": "text/plain", "content-disposition": "attachment", "filename": "attachment", "content": "This is a text attachment.\n"},
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": 8, "content-type": "text/plain", "content": "And this message is signed.\n\n-Carl\n"}]},
test: use notmuch_json_show_sanitize more places This makes the tests more robust against changing output formats, by allowing us to centralize fixes in the sanitization function. It is not appropriate for all cases, in particular it is unneeded when using test_json_nodes, and unhelpful when testing filenames.
2022-07-01 23:45:40 +02:00
{"id": 9, "content-type": "application/pgp-signature", "content-length": "NONZERO"}]}]}
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
test: Uniformly canonicalize actual and expected JSON Previously, we used a variety of ad-hoc canonicalizations for JSON output in the test suite, but were ultimately very sensitive to JSON irrelevancies such as whitespace. This introduces a new test comparison function, test_expect_equal_json, that first pretty-prints *both* the actual and expected JSON and the compares the result. The current implementation of this simply uses Python's json.tool to perform pretty-printing (with a fallback to the identity function if parsing fails). However, since the interface it introduces is semantically high-level, we could swap in other mechanisms in the future, such as another pretty-printer or something that does not re-order object keys (if we decide that we care about that). In general, this patch does not remove the existing ad-hoc canonicalization because it does no harm. We do have to remove the newline-after-comma rule from notmuch_json_show_sanitize and filter_show_json because it results in invalid JSON that cannot be pretty-printed. Most of this patch simply replaces test_expect_equal and test_expect_equal_file with test_expect_equal_json. It changes the expected JSON in a few places where sanitizers had placed newlines after commas inside strings.
2012-08-03 03:14:47 +02:00
test_expect_equal_json "$(cat OUTPUT)" "$(cat 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: Remove unnecessary JSON canonicalization Format canonicalization of JSON output is no longer necessary, so remove it. Value canonicalization (e.g., normalizing thread IDs) is still necessary, so all of the sanitization functions remain.
2012-08-03 03:14:48 +02:00
notmuch show --format=json --part=1 '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
cat <<EOF >EXPECTED
{"id": 1, "content-type": "multipart/signed", "content": [
{"id": 2, "content-type": "multipart/mixed", "content": [
cli/show: add content-disposition to structured output message parts Help the clients decide how to display parts. Test updates by Mark Walters <markwalters1009@gmail.com>. One more test fix by db
2017-02-26 19:33:48 +01:00
{"id": 3, "content-type": "message/rfc822", "content-disposition": "inline", "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": [
test: conform to content length, encoding fields Update tests to expect content-length and content-transfer-encoding fields in show --format=json output, for leaf parts with omitted body content.
2012-12-15 04:06:45 +01:00
{"id": 5, "content-type": "text/html", "content-length": 71},
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": 6, "content-type": "text/plain", "content": "This is an embedded message, with a multipart/alternative part.\n"}]}]}]},
cli/show: add content-disposition to structured output message parts Help the clients decide how to display parts. Test updates by Mark Walters <markwalters1009@gmail.com>. One more test fix by db
2017-02-26 19:33:48 +01:00
{"id": 7, "content-type": "text/plain", "content-disposition": "attachment", "filename": "attachment", "content": "This is a text attachment.\n"},
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": 8, "content-type": "text/plain", "content": "And this message is signed.\n\n-Carl\n"}]},
test: conform to content length, encoding fields Update tests to expect content-length and content-transfer-encoding fields in show --format=json output, for leaf parts with omitted body content.
2012-12-15 04:06:45 +01:00
{"id": 9, "content-type": "application/pgp-signature", "content-length": 197}]}
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
test: Uniformly canonicalize actual and expected JSON Previously, we used a variety of ad-hoc canonicalizations for JSON output in the test suite, but were ultimately very sensitive to JSON irrelevancies such as whitespace. This introduces a new test comparison function, test_expect_equal_json, that first pretty-prints *both* the actual and expected JSON and the compares the result. The current implementation of this simply uses Python's json.tool to perform pretty-printing (with a fallback to the identity function if parsing fails). However, since the interface it introduces is semantically high-level, we could swap in other mechanisms in the future, such as another pretty-printer or something that does not re-order object keys (if we decide that we care about that). In general, this patch does not remove the existing ad-hoc canonicalization because it does no harm. We do have to remove the newline-after-comma rule from notmuch_json_show_sanitize and filter_show_json because it results in invalid JSON that cannot be pretty-printed. Most of this patch simply replaces test_expect_equal and test_expect_equal_file with test_expect_equal_json. It changes the expected JSON in a few places where sanitizers had placed newlines after commas inside strings.
2012-08-03 03:14:47 +02:00
test_expect_equal_json "$(cat OUTPUT)" "$(cat 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: Remove unnecessary JSON canonicalization Format canonicalization of JSON output is no longer necessary, so remove it. Value canonicalization (e.g., normalizing thread IDs) is still necessary, so all of the sanitization functions remain.
2012-08-03 03:14:48 +02:00
notmuch show --format=json --part=2 '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
cat <<EOF >EXPECTED
{"id": 2, "content-type": "multipart/mixed", "content": [
cli/show: add content-disposition to structured output message parts Help the clients decide how to display parts. Test updates by Mark Walters <markwalters1009@gmail.com>. One more test fix by db
2017-02-26 19:33:48 +01:00
{"id": 3, "content-type": "message/rfc822", "content-disposition": "inline", "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": [
test: conform to content length, encoding fields Update tests to expect content-length and content-transfer-encoding fields in show --format=json output, for leaf parts with omitted body content.
2012-12-15 04:06:45 +01:00
{"id": 5, "content-type": "text/html", "content-length": 71},
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": 6, "content-type": "text/plain", "content": "This is an embedded message, with a multipart/alternative part.\n"}]}]}]},
cli/show: add content-disposition to structured output message parts Help the clients decide how to display parts. Test updates by Mark Walters <markwalters1009@gmail.com>. One more test fix by db
2017-02-26 19:33:48 +01:00
{"id": 7, "content-type": "text/plain", "content-disposition": "attachment", "filename": "attachment", "content": "This is a text attachment.\n"},
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": 8, "content-type": "text/plain", "content": "And this message is signed.\n\n-Carl\n"}]}
EOF
test: Uniformly canonicalize actual and expected JSON Previously, we used a variety of ad-hoc canonicalizations for JSON output in the test suite, but were ultimately very sensitive to JSON irrelevancies such as whitespace. This introduces a new test comparison function, test_expect_equal_json, that first pretty-prints *both* the actual and expected JSON and the compares the result. The current implementation of this simply uses Python's json.tool to perform pretty-printing (with a fallback to the identity function if parsing fails). However, since the interface it introduces is semantically high-level, we could swap in other mechanisms in the future, such as another pretty-printer or something that does not re-order object keys (if we decide that we care about that). In general, this patch does not remove the existing ad-hoc canonicalization because it does no harm. We do have to remove the newline-after-comma rule from notmuch_json_show_sanitize and filter_show_json because it results in invalid JSON that cannot be pretty-printed. Most of this patch simply replaces test_expect_equal and test_expect_equal_file with test_expect_equal_json. It changes the expected JSON in a few places where sanitizers had placed newlines after commas inside strings.
2012-08-03 03:14:47 +02:00
test_expect_equal_json "$(cat OUTPUT)" "$(cat 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
test_begin_subtest "--format=json --part=3, rfc822 part"
test: Remove unnecessary JSON canonicalization Format canonicalization of JSON output is no longer necessary, so remove it. Value canonicalization (e.g., normalizing thread IDs) is still necessary, so all of the sanitization functions remain.
2012-08-03 03:14:48 +02:00
notmuch show --format=json --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
cat <<EOF >EXPECTED
cli/show: add content-disposition to structured output message parts Help the clients decide how to display parts. Test updates by Mark Walters <markwalters1009@gmail.com>. One more test fix by db
2017-02-26 19:33:48 +01:00
{"id": 3, "content-type": "message/rfc822", "content-disposition": "inline", "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": [
test: conform to content length, encoding fields Update tests to expect content-length and content-transfer-encoding fields in show --format=json output, for leaf parts with omitted body content.
2012-12-15 04:06:45 +01:00
{"id": 5, "content-type": "text/html", "content-length": 71},
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": 6, "content-type": "text/plain", "content": "This is an embedded message, with a multipart/alternative part.\n"}]}]}]}
EOF
test: Uniformly canonicalize actual and expected JSON Previously, we used a variety of ad-hoc canonicalizations for JSON output in the test suite, but were ultimately very sensitive to JSON irrelevancies such as whitespace. This introduces a new test comparison function, test_expect_equal_json, that first pretty-prints *both* the actual and expected JSON and the compares the result. The current implementation of this simply uses Python's json.tool to perform pretty-printing (with a fallback to the identity function if parsing fails). However, since the interface it introduces is semantically high-level, we could swap in other mechanisms in the future, such as another pretty-printer or something that does not re-order object keys (if we decide that we care about that). In general, this patch does not remove the existing ad-hoc canonicalization because it does no harm. We do have to remove the newline-after-comma rule from notmuch_json_show_sanitize and filter_show_json because it results in invalid JSON that cannot be pretty-printed. Most of this patch simply replaces test_expect_equal and test_expect_equal_file with test_expect_equal_json. It changes the expected JSON in a few places where sanitizers had placed newlines after commas inside strings.
2012-08-03 03:14:47 +02:00
test_expect_equal_json "$(cat OUTPUT)" "$(cat 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
test_begin_subtest "--format=json --part=4, rfc822's multipart/alternative"
test: Remove unnecessary JSON canonicalization Format canonicalization of JSON output is no longer necessary, so remove it. Value canonicalization (e.g., normalizing thread IDs) is still necessary, so all of the sanitization functions remain.
2012-08-03 03:14:48 +02:00
notmuch show --format=json --part=4 '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
cat <<EOF >EXPECTED
{"id": 4, "content-type": "multipart/alternative", "content": [
test: conform to content length, encoding fields Update tests to expect content-length and content-transfer-encoding fields in show --format=json output, for leaf parts with omitted body content.
2012-12-15 04:06:45 +01:00
{"id": 5, "content-type": "text/html", "content-length": 71},
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": 6, "content-type": "text/plain", "content": "This is an embedded message, with a multipart/alternative part.\n"}]}
EOF
test: Uniformly canonicalize actual and expected JSON Previously, we used a variety of ad-hoc canonicalizations for JSON output in the test suite, but were ultimately very sensitive to JSON irrelevancies such as whitespace. This introduces a new test comparison function, test_expect_equal_json, that first pretty-prints *both* the actual and expected JSON and the compares the result. The current implementation of this simply uses Python's json.tool to perform pretty-printing (with a fallback to the identity function if parsing fails). However, since the interface it introduces is semantically high-level, we could swap in other mechanisms in the future, such as another pretty-printer or something that does not re-order object keys (if we decide that we care about that). In general, this patch does not remove the existing ad-hoc canonicalization because it does no harm. We do have to remove the newline-after-comma rule from notmuch_json_show_sanitize and filter_show_json because it results in invalid JSON that cannot be pretty-printed. Most of this patch simply replaces test_expect_equal and test_expect_equal_file with test_expect_equal_json. It changes the expected JSON in a few places where sanitizers had placed newlines after commas inside strings.
2012-08-03 03:14:47 +02:00
test_expect_equal_json "$(cat OUTPUT)" "$(cat 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
test_begin_subtest "--format=json --part=5, rfc822's html part"
test: Remove unnecessary JSON canonicalization Format canonicalization of JSON output is no longer necessary, so remove it. Value canonicalization (e.g., normalizing thread IDs) is still necessary, so all of the sanitization functions remain.
2012-08-03 03:14:48 +02:00
notmuch show --format=json --part=5 '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
cat <<EOF >EXPECTED
test: conform to content length, encoding fields Update tests to expect content-length and content-transfer-encoding fields in show --format=json output, for leaf parts with omitted body content.
2012-12-15 04:06:45 +01:00
{"id": 5, "content-type": "text/html", "content-length": 71}
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
test: Uniformly canonicalize actual and expected JSON Previously, we used a variety of ad-hoc canonicalizations for JSON output in the test suite, but were ultimately very sensitive to JSON irrelevancies such as whitespace. This introduces a new test comparison function, test_expect_equal_json, that first pretty-prints *both* the actual and expected JSON and the compares the result. The current implementation of this simply uses Python's json.tool to perform pretty-printing (with a fallback to the identity function if parsing fails). However, since the interface it introduces is semantically high-level, we could swap in other mechanisms in the future, such as another pretty-printer or something that does not re-order object keys (if we decide that we care about that). In general, this patch does not remove the existing ad-hoc canonicalization because it does no harm. We do have to remove the newline-after-comma rule from notmuch_json_show_sanitize and filter_show_json because it results in invalid JSON that cannot be pretty-printed. Most of this patch simply replaces test_expect_equal and test_expect_equal_file with test_expect_equal_json. It changes the expected JSON in a few places where sanitizers had placed newlines after commas inside strings.
2012-08-03 03:14:47 +02:00
test_expect_equal_json "$(cat OUTPUT)" "$(cat 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
test_begin_subtest "--format=json --part=6, rfc822's text part"
test: Remove unnecessary JSON canonicalization Format canonicalization of JSON output is no longer necessary, so remove it. Value canonicalization (e.g., normalizing thread IDs) is still necessary, so all of the sanitization functions remain.
2012-08-03 03:14:48 +02:00
notmuch show --format=json --part=6 '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
cat <<EOF >EXPECTED
{"id": 6, "content-type": "text/plain", "content": "This is an embedded message, with a multipart/alternative part.\n"}
EOF
test: Uniformly canonicalize actual and expected JSON Previously, we used a variety of ad-hoc canonicalizations for JSON output in the test suite, but were ultimately very sensitive to JSON irrelevancies such as whitespace. This introduces a new test comparison function, test_expect_equal_json, that first pretty-prints *both* the actual and expected JSON and the compares the result. The current implementation of this simply uses Python's json.tool to perform pretty-printing (with a fallback to the identity function if parsing fails). However, since the interface it introduces is semantically high-level, we could swap in other mechanisms in the future, such as another pretty-printer or something that does not re-order object keys (if we decide that we care about that). In general, this patch does not remove the existing ad-hoc canonicalization because it does no harm. We do have to remove the newline-after-comma rule from notmuch_json_show_sanitize and filter_show_json because it results in invalid JSON that cannot be pretty-printed. Most of this patch simply replaces test_expect_equal and test_expect_equal_file with test_expect_equal_json. It changes the expected JSON in a few places where sanitizers had placed newlines after commas inside strings.
2012-08-03 03:14:47 +02:00
test_expect_equal_json "$(cat OUTPUT)" "$(cat 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
test_begin_subtest "--format=json --part=7, inline attachment"
test: Remove unnecessary JSON canonicalization Format canonicalization of JSON output is no longer necessary, so remove it. Value canonicalization (e.g., normalizing thread IDs) is still necessary, so all of the sanitization functions remain.
2012-08-03 03:14:48 +02:00
notmuch show --format=json --part=7 '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
cat <<EOF >EXPECTED
cli/show: add content-disposition to structured output message parts Help the clients decide how to display parts. Test updates by Mark Walters <markwalters1009@gmail.com>. One more test fix by db
2017-02-26 19:33:48 +01:00
{"id": 7,
"content-type": "text/plain",
"filename": "attachment",
"content": "This is a text attachment.\n",
"content-disposition": "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
EOF
test: Uniformly canonicalize actual and expected JSON Previously, we used a variety of ad-hoc canonicalizations for JSON output in the test suite, but were ultimately very sensitive to JSON irrelevancies such as whitespace. This introduces a new test comparison function, test_expect_equal_json, that first pretty-prints *both* the actual and expected JSON and the compares the result. The current implementation of this simply uses Python's json.tool to perform pretty-printing (with a fallback to the identity function if parsing fails). However, since the interface it introduces is semantically high-level, we could swap in other mechanisms in the future, such as another pretty-printer or something that does not re-order object keys (if we decide that we care about that). In general, this patch does not remove the existing ad-hoc canonicalization because it does no harm. We do have to remove the newline-after-comma rule from notmuch_json_show_sanitize and filter_show_json because it results in invalid JSON that cannot be pretty-printed. Most of this patch simply replaces test_expect_equal and test_expect_equal_file with test_expect_equal_json. It changes the expected JSON in a few places where sanitizers had placed newlines after commas inside strings.
2012-08-03 03:14:47 +02:00
test_expect_equal_json "$(cat OUTPUT)" "$(cat 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
test_begin_subtest "--format=json --part=8, plain text part"
test: Remove unnecessary JSON canonicalization Format canonicalization of JSON output is no longer necessary, so remove it. Value canonicalization (e.g., normalizing thread IDs) is still necessary, so all of the sanitization functions remain.
2012-08-03 03:14:48 +02:00
notmuch show --format=json --part=8 '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
cat <<EOF >EXPECTED
{"id": 8, "content-type": "text/plain", "content": "And this message is signed.\n\n-Carl\n"}
EOF
test: Uniformly canonicalize actual and expected JSON Previously, we used a variety of ad-hoc canonicalizations for JSON output in the test suite, but were ultimately very sensitive to JSON irrelevancies such as whitespace. This introduces a new test comparison function, test_expect_equal_json, that first pretty-prints *both* the actual and expected JSON and the compares the result. The current implementation of this simply uses Python's json.tool to perform pretty-printing (with a fallback to the identity function if parsing fails). However, since the interface it introduces is semantically high-level, we could swap in other mechanisms in the future, such as another pretty-printer or something that does not re-order object keys (if we decide that we care about that). In general, this patch does not remove the existing ad-hoc canonicalization because it does no harm. We do have to remove the newline-after-comma rule from notmuch_json_show_sanitize and filter_show_json because it results in invalid JSON that cannot be pretty-printed. Most of this patch simply replaces test_expect_equal and test_expect_equal_file with test_expect_equal_json. It changes the expected JSON in a few places where sanitizers had placed newlines after commas inside strings.
2012-08-03 03:14:47 +02:00
test_expect_equal_json "$(cat OUTPUT)" "$(cat 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
test_begin_subtest "--format=json --part=9, pgp signature (unverified)"
test: Remove unnecessary JSON canonicalization Format canonicalization of JSON output is no longer necessary, so remove it. Value canonicalization (e.g., normalizing thread IDs) is still necessary, so all of the sanitization functions remain.
2012-08-03 03:14:48 +02:00
notmuch show --format=json --part=9 '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
cat <<EOF >EXPECTED
test: conform to content length, encoding fields Update tests to expect content-length and content-transfer-encoding fields in show --format=json output, for leaf parts with omitted body content.
2012-12-15 04:06:45 +01:00
{"id": 9, "content-type": "application/pgp-signature", "content-length": 197}
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
test: Uniformly canonicalize actual and expected JSON Previously, we used a variety of ad-hoc canonicalizations for JSON output in the test suite, but were ultimately very sensitive to JSON irrelevancies such as whitespace. This introduces a new test comparison function, test_expect_equal_json, that first pretty-prints *both* the actual and expected JSON and the compares the result. The current implementation of this simply uses Python's json.tool to perform pretty-printing (with a fallback to the identity function if parsing fails). However, since the interface it introduces is semantically high-level, we could swap in other mechanisms in the future, such as another pretty-printer or something that does not re-order object keys (if we decide that we care about that). In general, this patch does not remove the existing ad-hoc canonicalization because it does no harm. We do have to remove the newline-after-comma rule from notmuch_json_show_sanitize and filter_show_json because it results in invalid JSON that cannot be pretty-printed. Most of this patch simply replaces test_expect_equal and test_expect_equal_file with test_expect_equal_json. It changes the expected JSON in a few places where sanitizers had placed newlines after commas inside strings.
2012-08-03 03:14:47 +02:00
test_expect_equal_json "$(cat OUTPUT)" "$(cat 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: require test_begin_subtest before test_expect_success Unify the subtests by requiring test_begin_subtest before test_expect_success. (Similar change for test_expect_code will follow.) This increases clarity in the test scripts by having a separate line for the start of the subtest with the heading, and makes it possible to simplify the test infrastructure by making all subtests similar.
2017-02-26 14:43:00 +01:00
test_begin_subtest "--format=json --part=10, no part, expect error"
test_expect_success "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: standardize argument order to test_expect_equal_file It is annoying to debug failing tests when the interpretation of the diffs is reversed for some tests.
2017-04-05 02:36:29 +02:00
test_expect_equal_file "${MAIL_DIR}"/multipart OUTPUT
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: use notmuch_json_show_sanitize more places This makes the tests more robust against changing output formats, by allowing us to centralize fixes in the sanitization function. It is not appropriate for all cases, in particular it is unneeded when using test_json_nodes, and unhelpful when testing filenames.
2022-07-01 23:45:40 +02:00
notmuch show --format=raw --part=0 'id:87liy5ap00.fsf@yoom.home.cworth.org' | notmuch_json_show_sanitize >OUTPUT
test: standardize argument order to test_expect_equal_file It is annoying to debug failing tests when the interpretation of the diffs is reversed for some tests.
2017-04-05 02:36:29 +02:00
test_expect_equal_file "${MAIL_DIR}"/multipart OUTPUT
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
test: mark inclusion of headers as broken in gmime-2.x The output of headers here reflects an underlying bug / quirk of gmime-2.6.
2017-06-03 19:47:36 +02:00
test_expect_equal_file multipart_body OUTPUT
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: standardize argument order to test_expect_equal_file It is annoying to debug failing tests when the interpretation of the diffs is reversed for some tests.
2017-04-05 02:36:29 +02:00
test_expect_equal_file EXPECTED OUTPUT
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: standardize argument order to test_expect_equal_file It is annoying to debug failing tests when the interpretation of the diffs is reversed for some tests.
2017-04-05 02:36:29 +02:00
test_expect_equal_file embedded_message 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: 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: mark inclusion of headers as broken in gmime-2.x The output of headers here reflects an underlying bug / quirk of gmime-2.6.
2017-06-03 19:47:36 +02:00
test_expect_equal_file embedded_message_body OUTPUT
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: standardize argument order to test_expect_equal_file It is annoying to debug failing tests when the interpretation of the diffs is reversed for some tests.
2017-04-05 02:36:29 +02:00
test_expect_equal_file EXPECTED OUTPUT
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: standardize argument order to test_expect_equal_file It is annoying to debug failing tests when the interpretation of the diffs is reversed for some tests.
2017-04-05 02:36:29 +02:00
test_expect_equal_file EXPECTED 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_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: standardize argument order to test_expect_equal_file It is annoying to debug failing tests when the interpretation of the diffs is reversed for some tests.
2017-04-05 02:36:29 +02:00
test_expect_equal_file EXPECTED OUTPUT
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: standardize argument order to test_expect_equal_file It is annoying to debug failing tests when the interpretation of the diffs is reversed for some tests.
2017-04-05 02:36:29 +02:00
test_expect_equal_file EXPECTED OUTPUT
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: standardize argument order to test_expect_equal_file It is annoying to debug failing tests when the interpretation of the diffs is reversed for some tests.
2017-04-05 02:36:29 +02:00
test_expect_equal_file EXPECTED OUTPUT
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: require test_begin_subtest before test_expect_success Unify the subtests by requiring test_begin_subtest before test_expect_success. (Similar change for test_expect_code will follow.) This increases clarity in the test scripts by having a separate line for the start of the subtest with the heading, and makes it possible to simplify the test infrastructure by making all subtests similar.
2017-02-26 14:43:00 +01:00
test_begin_subtest "--format=raw --part=10, no part, expect error"
test_expect_success "notmuch show --format=raw --part=8 '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=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: standardize argument order to test_expect_equal_file It is annoying to debug failing tests when the interpretation of the diffs is reversed for some tests.
2017-04-05 02:36:29 +02:00
test_expect_equal_file EXPECTED OUTPUT
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: require test_begin_subtest before test_expect_success Unify the subtests by requiring test_begin_subtest before test_expect_success. (Similar change for test_expect_code will follow.) This increases clarity in the test scripts by having a separate line for the start of the subtest with the heading, and makes it possible to simplify the test infrastructure by making all subtests similar.
2017-02-26 14:43:00 +01:00
test_begin_subtest "--format=mbox --part=1, incompatible, expect error"
test_expect_success "! notmuch show --format=mbox --part=1 '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: 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: standardize argument order to test_expect_equal_file It is annoying to debug failing tests when the interpretation of the diffs is reversed for some tests.
2017-04-05 02:36:29 +02:00
test_expect_equal_file EXPECTED OUTPUT
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"
notmuch reply --format=json 'id:87liy5ap00.fsf@yoom.home.cworth.org' | notmuch_json_show_sanitize >OUTPUT
test: pass expected output through json_sanitize in 2 places This makes the tests more robust against changes in the sanitization rules.
2013-12-08 09:39:05 +01:00
notmuch_json_show_sanitize <<EOF >EXPECTED
test: Add broken test for the new JSON reply format.
2012-03-18 17:32:33 +01:00
{"reply-headers": {"Subject": "Re: Multipart message",
"From": "Notmuch Test Suite <test_suite@notmuchmail.org>",
test: Uniformly canonicalize actual and expected JSON Previously, we used a variety of ad-hoc canonicalizations for JSON output in the test suite, but were ultimately very sensitive to JSON irrelevancies such as whitespace. This introduces a new test comparison function, test_expect_equal_json, that first pretty-prints *both* the actual and expected JSON and the compares the result. The current implementation of this simply uses Python's json.tool to perform pretty-printing (with a fallback to the identity function if parsing fails). However, since the interface it introduces is semantically high-level, we could swap in other mechanisms in the future, such as another pretty-printer or something that does not re-order object keys (if we decide that we care about that). In general, this patch does not remove the existing ad-hoc canonicalization because it does no harm. We do have to remove the newline-after-comma rule from notmuch_json_show_sanitize and filter_show_json because it results in invalid JSON that cannot be pretty-printed. Most of this patch simply replaces test_expect_equal and test_expect_equal_file with test_expect_equal_json. It changes the expected JSON in a few places where sanitizers had placed newlines after commas inside strings.
2012-08-03 03:14:47 +02:00
"To": "Carl Worth <cworth@cworth.org>, cworth@cworth.org",
test: Add broken test for the new JSON reply format.
2012-03-18 17:32:33 +01:00
"In-reply-to": "<87liy5ap00.fsf@yoom.home.cworth.org>",
reply: Remove extraneous space from generated References Previously, the References header code seemed to assume notmuch_message_get_header would return NULL if the header was not present, but it actually returns "". As a result of this, it was inserting an unnecessary space when concatenating an empty or missing original references header with the new reference. This shows up in only two tests because the text reply format later passes the whole reply template through g_mime_filter_headers, which has the side effect of stripping out this extra space.
2013-08-16 17:35:42 +02:00
"References": "<87liy5ap00.fsf@yoom.home.cworth.org>"},
test: Add broken test for the new JSON reply format.
2012-03-18 17:32:33 +01:00
"original": {"id": "XXXXX",
cli/show: emit new whole-message crypto status output This allows MUAs that don't want to think about per-mime-part cryptographic status to have a simple high-level overview of the message's cryptographic state. Sensibly structured encrypted and/or signed messages will work fine with this. The only requirement for the simplest encryption + signing is that the message have all of its encryption and signing protection (the "cryptographic envelope") in a contiguous set of MIME layers at the very outside of the message itself. This is because messages with some subparts signed or encrypted, but with other subparts with no cryptographic protection is very difficult to reason about, and even harder for the user to make sense of or work with. For further characterization of the Cryptographic Envelope and some of the usability tradeoffs, see here: https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html#cryptographic-envelope
2019-05-25 20:04:06 +02:00
"crypto": {},
test: Add broken test for the new JSON reply format.
2012-03-18 17:32:33 +01:00
"match": false,
"excluded": false,
cli/show: list all filenames of a message in the formatted output Instead of just having the first filename for the message, list all duplicate filenames of the message as a list in the formatted outputs. This bumps the format version to 3.
2017-02-25 14:31:31 +01:00
"filename": ["YYYYY"],
test: Add broken test for the new JSON reply format.
2012-03-18 17:32:33 +01:00
"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",
test: Uniformly canonicalize actual and expected JSON Previously, we used a variety of ad-hoc canonicalizations for JSON output in the test suite, but were ultimately very sensitive to JSON irrelevancies such as whitespace. This introduces a new test comparison function, test_expect_equal_json, that first pretty-prints *both* the actual and expected JSON and the compares the result. The current implementation of this simply uses Python's json.tool to perform pretty-printing (with a fallback to the identity function if parsing fails). However, since the interface it introduces is semantically high-level, we could swap in other mechanisms in the future, such as another pretty-printer or something that does not re-order object keys (if we decide that we care about that). In general, this patch does not remove the existing ad-hoc canonicalization because it does no harm. We do have to remove the newline-after-comma rule from notmuch_json_show_sanitize and filter_show_json because it results in invalid JSON that cannot be pretty-printed. Most of this patch simply replaces test_expect_equal and test_expect_equal_file with test_expect_equal_json. It changes the expected JSON in a few places where sanitizers had placed newlines after commas inside strings.
2012-08-03 03:14:47 +02:00
"Date": "Fri, 05 Jan 2001 15:43:57 +0000"},
test: Add broken test for the new JSON reply format.
2012-03-18 17:32:33 +01:00
"body": [{"id": 1,
"content-type": "multipart/signed",
"content": [{"id": 2,
"content-type": "multipart/mixed",
"content": [{"id": 3,
"content-type": "message/rfc822",
cli/show: add content-disposition to structured output message parts Help the clients decide how to display parts. Test updates by Mark Walters <markwalters1009@gmail.com>. One more test fix by db
2017-02-26 19:33:48 +01:00
"content-disposition": "inline",
test: Add broken test for the new JSON reply format.
2012-03-18 17:32:33 +01:00
"content": [{"headers": {"Subject": "html message",
"From": "Carl Worth <cworth@cworth.org>",
"To": "cworth@cworth.org",
test: Uniformly canonicalize actual and expected JSON Previously, we used a variety of ad-hoc canonicalizations for JSON output in the test suite, but were ultimately very sensitive to JSON irrelevancies such as whitespace. This introduces a new test comparison function, test_expect_equal_json, that first pretty-prints *both* the actual and expected JSON and the compares the result. The current implementation of this simply uses Python's json.tool to perform pretty-printing (with a fallback to the identity function if parsing fails). However, since the interface it introduces is semantically high-level, we could swap in other mechanisms in the future, such as another pretty-printer or something that does not re-order object keys (if we decide that we care about that). In general, this patch does not remove the existing ad-hoc canonicalization because it does no harm. We do have to remove the newline-after-comma rule from notmuch_json_show_sanitize and filter_show_json because it results in invalid JSON that cannot be pretty-printed. Most of this patch simply replaces test_expect_equal and test_expect_equal_file with test_expect_equal_json. It changes the expected JSON in a few places where sanitizers had placed newlines after commas inside strings.
2012-08-03 03:14:47 +02:00
"Date": "Fri, 05 Jan 2001 15:42:57 +0000"},
test: Add broken test for the new JSON reply format.
2012-03-18 17:32:33 +01:00
"body": [{"id": 4,
"content-type": "multipart/alternative",
"content": [{"id": 5,
test: conform to content length, encoding fields Update tests to expect content-length and content-transfer-encoding fields in show --format=json output, for leaf parts with omitted body content.
2012-12-15 04:06:45 +01:00
"content-type": "text/html",
"content-length": 71},
test: Add broken test for the new JSON reply format.
2012-03-18 17:32:33 +01:00
{"id": 6,
"content-type": "text/plain",
test: Uniformly canonicalize actual and expected JSON Previously, we used a variety of ad-hoc canonicalizations for JSON output in the test suite, but were ultimately very sensitive to JSON irrelevancies such as whitespace. This introduces a new test comparison function, test_expect_equal_json, that first pretty-prints *both* the actual and expected JSON and the compares the result. The current implementation of this simply uses Python's json.tool to perform pretty-printing (with a fallback to the identity function if parsing fails). However, since the interface it introduces is semantically high-level, we could swap in other mechanisms in the future, such as another pretty-printer or something that does not re-order object keys (if we decide that we care about that). In general, this patch does not remove the existing ad-hoc canonicalization because it does no harm. We do have to remove the newline-after-comma rule from notmuch_json_show_sanitize and filter_show_json because it results in invalid JSON that cannot be pretty-printed. Most of this patch simply replaces test_expect_equal and test_expect_equal_file with test_expect_equal_json. It changes the expected JSON in a few places where sanitizers had placed newlines after commas inside strings.
2012-08-03 03:14:47 +02:00
"content": "This is an embedded message, with a multipart/alternative part.\n"}]}]}]},
test: Add broken test for the new JSON reply format.
2012-03-18 17:32:33 +01:00
{"id": 7,
"content-type": "text/plain",
cli/show: add content-disposition to structured output message parts Help the clients decide how to display parts. Test updates by Mark Walters <markwalters1009@gmail.com>. One more test fix by db
2017-02-26 19:33:48 +01:00
"content-disposition": "attachment",
test: normalize only message filenames in show json notmuch_json_show_sanitize replaced "filename" field values even in part structures, where the value is predictable. Make it only normalize the filename value if it is an absolute path (begins with slash), which is true of the Maildir filenames that were intended to be normalized away.
2012-12-15 04:06:42 +01:00
"filename": "attachment",
test: Add broken test for the new JSON reply format.
2012-03-18 17:32:33 +01:00
"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,
test: conform to content length, encoding fields Update tests to expect content-length and content-transfer-encoding fields in show --format=json output, for leaf parts with omitted body content.
2012-12-15 04:06:45 +01:00
"content-type": "application/pgp-signature",
"content-length": 197}]}]}}
test: Add broken test for the new JSON reply format.
2012-03-18 17:32:33 +01:00
EOF
test: Uniformly canonicalize actual and expected JSON Previously, we used a variety of ad-hoc canonicalizations for JSON output in the test suite, but were ultimately very sensitive to JSON irrelevancies such as whitespace. This introduces a new test comparison function, test_expect_equal_json, that first pretty-prints *both* the actual and expected JSON and the compares the result. The current implementation of this simply uses Python's json.tool to perform pretty-printing (with a fallback to the identity function if parsing fails). However, since the interface it introduces is semantically high-level, we could swap in other mechanisms in the future, such as another pretty-printer or something that does not re-order object keys (if we decide that we care about that). In general, this patch does not remove the existing ad-hoc canonicalization because it does no harm. We do have to remove the newline-after-comma rule from notmuch_json_show_sanitize and filter_show_json because it results in invalid JSON that cannot be pretty-printed. Most of this patch simply replaces test_expect_equal and test_expect_equal_file with test_expect_equal_json. It changes the expected JSON in a few places where sanitizers had placed newlines after commas inside strings.
2012-08-03 03:14:47 +02:00
test_expect_equal_json "$(cat OUTPUT)" "$(cat EXPECTED)"
test: Add broken test for the new JSON reply format.
2012-03-18 17:32:33 +01:00
test: Add test showing notmuch corrupts a part with a CRLF pair in it Since commit 2f8871df6ea3c0b44f85a0fc1b4f58a6b70b0a0e notmuch has been using a function (show_part_content) originally written only for text parts to save all MIME parts. The problem with this is that this function converts CRLF pairs to LF only and optionally converts to UTF-8 encoding. These two conversions have the potential to corrupt binary data when passed through the function. This test demonstrates that corruption, and so fails currently, until we fix the bug.
2011-06-01 00:39:26 +02:00
test_begin_subtest "'notmuch show --part' does not corrupt a part with CRLF pair"
notmuch show --format=raw --part=3 id:base64-part-with-crlf > crlf.out
removed use of 'echo -n' (and echo -n -e ...) In most cases used printf %s ... instead. echo -n > file lines to create empty / truncate files were changed to : > file lines, like done in in test-lib-emacs.sh And one echo -n " " replaced with use of sed "s/^/ /" in next line.
2022-02-20 23:30:45 +01:00
printf "\xEF\x0D\x0A" > crlf.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_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: test notmuch show --include-html option Test new --include-html option added to notmuch show command with json output message parts containing text in latin1 and utf8 format.
2013-08-24 17:29:30 +02:00
# The ISO-8859-1 encoding of U+00BD is a single byte: octal 275
# (Portability note: Dollar-Single ($'...', ANSI C-style escape sequences)
# quoting works on bash, ksh, zsh, *BSD sh but not on dash, ash nor busybox sh)
readonly u_00bd_latin1=$'\275'
# The Unicode fraction symbol 1/2 is U+00BD and is encoded
# in UTF-8 as two bytes: octal 302 275
readonly u_00bd_utf8=$'\302\275'
cat <<EOF > ${MAIL_DIR}/include-html
From: A <a@example.com>
To: B <b@example.com>
Subject: html message
Date: Sat, 01 January 2000 00:00:00 +0000
Message-ID: <htmlmessage>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="==-=="
--==-==
Content-Type: text/html; charset=UTF-8
<p>0.5 equals ${u_00bd_utf8}</p>
--==-==
Content-Type: text/html; charset=ISO-8859-1
<p>0.5 equals ${u_00bd_latin1}</p>
--==-==
Content-Type: text/plain; charset=UTF-8
0.5 equals ${u_00bd_utf8}
--==-==--
EOF
notmuch new > /dev/null
test: more style fixes In order to fit the git coding style. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
2021-05-15 22:47:40 +02:00
cat_expected_head () {
test: test notmuch show --include-html option Test new --include-html option added to notmuch show command with json output message parts containing text in latin1 and utf8 format.
2013-08-24 17:29:30 +02:00
cat <<EOF
test: use notmuch_json_show_sanitize more places This makes the tests more robust against changing output formats, by allowing us to centralize fixes in the sanitization function. It is not appropriate for all cases, in particular it is unneeded when using test_json_nodes, and unhelpful when testing filenames.
2022-07-01 23:45:40 +02:00
[[[{"id": "XXXXX", "match":true, "excluded": false, "date_relative":"2000-01-01",
cli/show: emit new whole-message crypto status output This allows MUAs that don't want to think about per-mime-part cryptographic status to have a simple high-level overview of the message's cryptographic state. Sensibly structured encrypted and/or signed messages will work fine with this. The only requirement for the simplest encryption + signing is that the message have all of its encryption and signing protection (the "cryptographic envelope") in a contiguous set of MIME layers at the very outside of the message itself. This is because messages with some subparts signed or encrypted, but with other subparts with no cryptographic protection is very difficult to reason about, and even harder for the user to make sense of or work with. For further characterization of the Cryptographic Envelope and some of the usability tradeoffs, see here: https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html#cryptographic-envelope
2019-05-25 20:04:06 +02:00
"crypto": {},
test: test notmuch show --include-html option Test new --include-html option added to notmuch show command with json output message parts containing text in latin1 and utf8 format.
2013-08-24 17:29:30 +02:00
"timestamp": 946684800,
test: use notmuch_json_show_sanitize more places This makes the tests more robust against changing output formats, by allowing us to centralize fixes in the sanitization function. It is not appropriate for all cases, in particular it is unneeded when using test_json_nodes, and unhelpful when testing filenames.
2022-07-01 23:45:40 +02:00
"filename": ["YYYYY"],
test: test notmuch show --include-html option Test new --include-html option added to notmuch show command with json output message parts containing text in latin1 and utf8 format.
2013-08-24 17:29:30 +02:00
"tags": ["inbox", "unread"],
"headers": { "Date": "Sat, 01 Jan 2000 00:00:00 +0000", "From": "A <a@example.com>",
"Subject": "html message", "To": "B <b@example.com>"},
"body": [{
"content-type": "multipart/alternative", "id": 1,
EOF
}
cat_expected_head > EXPECTED.nohtml
cat <<EOF >> EXPECTED.nohtml
"content": [
test: use notmuch_json_show_sanitize more places This makes the tests more robust against changing output formats, by allowing us to centralize fixes in the sanitization function. It is not appropriate for all cases, in particular it is unneeded when using test_json_nodes, and unhelpful when testing filenames.
2022-07-01 23:45:40 +02:00
{ "id": 2, "content-charset": "UTF-8", "content-length": "NONZERO", "content-type": "text/html"},
{ "id": 3, "content-charset": "ISO-8859-1", "content-length": "NONZERO", "content-type": "text/html"},
test: test notmuch show --include-html option Test new --include-html option added to notmuch show command with json output message parts containing text in latin1 and utf8 format.
2013-08-24 17:29:30 +02:00
{ "id": 4, "content-type": "text/plain", "content": "0.5 equals \\u00bd\\n"}
]}]},[]]]]
EOF
# Both the UTF-8 and ISO-8859-1 part should have U+00BD
cat_expected_head > EXPECTED.withhtml
cat <<EOF >> EXPECTED.withhtml
"content": [
{ "id": 2, "content-type": "text/html", "content": "<p>0.5 equals \\u00bd</p>\\n"},
{ "id": 3, "content-type": "text/html", "content": "<p>0.5 equals \\u00bd</p>\\n"},
{ "id": 4, "content-type": "text/plain", "content": "0.5 equals \\u00bd\\n"}
]}]},[]]]]
EOF
test_begin_subtest "html parts excluded by default"
test: use notmuch_json_show_sanitize more places This makes the tests more robust against changing output formats, by allowing us to centralize fixes in the sanitization function. It is not appropriate for all cases, in particular it is unneeded when using test_json_nodes, and unhelpful when testing filenames.
2022-07-01 23:45:40 +02:00
notmuch show --format=json id:htmlmessage | notmuch_json_show_sanitize > OUTPUT
test: test notmuch show --include-html option Test new --include-html option added to notmuch show command with json output message parts containing text in latin1 and utf8 format.
2013-08-24 17:29:30 +02:00
test_expect_equal_json "$(cat OUTPUT)" "$(cat EXPECTED.nohtml)"
test_begin_subtest "html parts included"
test: use notmuch_json_show_sanitize more places This makes the tests more robust against changing output formats, by allowing us to centralize fixes in the sanitization function. It is not appropriate for all cases, in particular it is unneeded when using test_json_nodes, and unhelpful when testing filenames.
2022-07-01 23:45:40 +02:00
notmuch show --format=json --include-html id:htmlmessage | notmuch_json_show_sanitize > OUTPUT
test: test notmuch show --include-html option Test new --include-html option added to notmuch show command with json output message parts containing text in latin1 and utf8 format.
2013-08-24 17:29:30 +02:00
test_expect_equal_json "$(cat OUTPUT)" "$(cat EXPECTED.withhtml)"
test: Add failing unit tests for indexed mime types Adds three failing unit tests for searching of mime-types. An attempt was made at adding a negative test (i.e. searching for a non-existent mime-type and ensuring it didn't return a message), but that test would always pass making it pointless.
2015-01-23 00:43:36 +01:00
test_begin_subtest "indexes mime-type #1"
output=$(notmuch search mimetype:application/unique_identifier | notmuch_search_sanitize)
test_expect_equal "$output" "thread:XXX 2014-01-12 [1/1] Todd; odd content types (inbox unread)"
test_begin_subtest "indexes mime-type #2"
output=$(notmuch search mimetype:text/some_other_identifier | notmuch_search_sanitize)
test_expect_equal "$output" "thread:XXX 2014-01-12 [1/1] Todd; odd content types (inbox unread)"
test_begin_subtest "indexes mime-type #3"
output=$(notmuch search from:todd and mimetype:multipart/alternative | notmuch_search_sanitize)
test_expect_equal "$output" "thread:XXX 2014-01-12 [1/1] Todd; odd content types (inbox unread)"
tests: add test for case insensitive Content-Disposition This is broken now, but will be fixed in the next commit
2015-10-06 12:20:46 +02:00
test_begin_subtest "case of Content-Disposition doesn't matter for indexing"
cat <<EOF > ${MAIL_DIR}/content-disposition
Return-path: <david@tethera.net>
Envelope-to: david@tethera.net
Delivery-date: Sun, 04 Oct 2015 09:16:03 -0300
Received: from gitolite.debian.net ([87.98.215.224])
by yantan.tethera.net with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128)
(Exim 4.80)
(envelope-from <david@tethera.net>)
id 1ZiiCx-0007iz-RK
for david@tethera.net; Sun, 04 Oct 2015 09:16:03 -0300
Received: from remotemail by gitolite.debian.net with local (Exim 4.80)
(envelope-from <david@tethera.net>)
id 1ZiiC8-0002Rz-Uf; Sun, 04 Oct 2015 12:15:12 +0000
Received: (nullmailer pid 28621 invoked by uid 1000); Sun, 04 Oct 2015
12:14:53 -0000
From: David Bremner <david@tethera.net>
To: David Bremner <david@tethera.net>
Subject: test attachment
User-Agent: Notmuch/0.20.2+93~g33c8777 (http://notmuchmail.org) Emacs/24.5.1
(x86_64-pc-linux-gnu)
Date: Sun, 04 Oct 2015 09:14:53 -0300
Message-ID: <87io6m96f6.fsf@zancas.localnet>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
--=-=-=
Content-Type: text/plain
Content-Disposition: ATTACHMENT; filename=hello.txt
Content-Description: this is a very exciting file
hello
--=-=-=
Content-Type: text/plain
world
--=-=-=--
EOF
NOTMUCH_NEW
cat <<EOF > EXPECTED
attachment
inbox
unread
EOF
notmuch search --output=tags id:87io6m96f6.fsf@zancas.localnet > OUTPUT
test_expect_equal_file EXPECTED OUTPUT
test: test notmuch show --include-html option Test new --include-html option added to notmuch show command with json output message parts containing text in latin1 and utf8 format.
2013-08-24 17:29:30 +02:00
test_done
Reference in a new issue Copy permalink