Making the test result output robust against dodgy bytestrings is a worthy goal, but there are issues with the specifics here. Most generally, I think testtools is the place to start.
There are three things this patch is making 'safe':
* Exception instances from testtools
Already been run through an encoding and decoding process. There *are* issues like bug 501166 that need fixing upstream.
* Diffs where one text is a (non-ascii) str and the other is unicode
This is undecidable as the function does not know the encoding of the bytestring. Just escaping both inputs can result in a bogus pass, asserting the types are the same would catch badly written tests.
Making the test result output robust against dodgy bytestrings is a worthy goal, but there are issues with the specifics here. Most generally, I think testtools is the place to start.
There are three things this patch is making 'safe':
* Test descriptions, which come from test ids /lists. ubuntu. com/archives/ bazaar/ 2008q3/ 045619. html>
Always ascii, as noted by John last time around:
<https:/
* Exception instances from testtools
Already been run through an encoding and decoding process. There *are* issues like bug 501166 that need fixing upstream.
* Diffs where one text is a (non-ascii) str and the other is unicode
This is undecidable as the function does not know the encoding of the bytestring. Just escaping both inputs can result in a bogus pass, asserting the types are the same would catch badly written tests.