The attached patch includes additional unit tests for the email module,
and splits pre-existing test_header_encode() and test_decode() functions
into individual test functions.

Do we need each sample--(input -> expected output)--to be its own unittest function?

Why not something like (pseudo-code):

expected = {
  'input1': 'output1',
  'input2': 'output2',
}

def test_encode(self):    # collapse all
    for input, output in expected.items():
        self._encode(input, output)    # test logic

Until unittest learns to do parameterized tests, it's nice to have each test be separate so that you can easily see which test cases are failing.  (A number of the existing email tests have a lot of tests in each "unit" test, and this can make debugging more difficult, as I know well.)

I've been known to synthesize parameterized tests in my unit tests to save myself some typing, but Michael has already done the typing here...

New changeset 3dbea3fa73fb by R David Murray in branch '3.1':
#11589: add additional tests for the email quoprimime module.
http://hg.python.org/cpython/rev/3dbea3fa73fb

New changeset 04c9c831803b by R David Murray in branch '3.2':
Merge #11589: add additional tests for the email quoprimime module.
http://hg.python.org/cpython/rev/04c9c831803b

New changeset 2f4865834695 by R David Murray in branch 'default':
Merge #11589: add additional tests for the email quoprimime module.
http://hg.python.org/cpython/rev/2f4865834695

Thanks, Michael!  I tweaked the patch slightly: deleted that test-writing-helper check you had marked with the XXX, and renamed the helper test methods to _test_XXX.  I also didn't wind up applying it to 2.7 because hg doesn't support merge markers when doing a transplant and there were conflicts.  Not worth the extra effort that would be required.