testtools-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxx>]

I don't actually know how to fix this. Looking over the conversation,
I'm not sure why a special exception class is called for, instead of
passing in a better string.

** Summary changed:

- assertThat sometimes generates unprintable AssertionErrors
+ assertThat(..., verbose=True) sometimes generates unprintable AssertionErrors

-- 
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