← Back to team overview

testtools-dev team mailing list archive

[Bug 804127] Re: assertThat(..., verbose=True) sometimes generates unprintable AssertionErrors

 

Certainly just mangling the string in the exception to be ascii-only on
Python 2 works as well. The problem is that loses information that
testtools could use.

Not having a clear interface means other matchers are likely to fall
into this kind of trap with unicode, for instance the StartsWith
matcher, and after <lp:~jml/testtools/nicer-regex-fail> MatchesRegex
too.

-- 
You received this bug notification because you are a member of testtools
developers, which is subscribed to testtools.
https://bugs.launchpad.net/bugs/804127

Title:
  assertThat(..., verbose=True) sometimes generates unprintable
  AssertionErrors

Status in testtools:
  Triaged

Bug description:
  The assertThat method for use with matchers creates AssertionError
  instances that don't stringify on Python 2.4, 2.5, and some 2.6 minor
  versions when used with a non-ascii unicode argument. The
  testtools.testresults code has some robustness that means the failure
  is still printed, but other runners may break if the
  UnicodeEncodeError from trying to stringify the exception propagates.

  Instead of the expected output, these older Pythons get:

  Traceback (most recent call last):
    ...
      self.assertThat(u"\xa7", Equals(u"a"), verbose=True)
    File "C:\Python24\Lib\site-packages\testtools\testcase.py", line 351, in assertThat
      self.fail('Match failed. Matchee: "%s"\nMatcher: %s\nDifference: %s\n'
  AssertionError: <unprintable AssertionError object>

To manage notifications about this bug go to:
https://bugs.launchpad.net/testtools/+bug/804127/+subscriptions


References