unittest.failureExeption(msg, data=None): add optional data kwarg to failureException() of unittest
Hi, what do you think about the idea to add an optional data kwarg to unittest.failureExeption()? Up to now a the exception class "failureException" does only get a message which is a string. I would like to log the failed Exceptions to a structured logging back end. Parsing the string message to extract the real value is possible, but somehow ugly and error prone. My high level use case: Have a system (maybe ELK-Stack) to investigate if a test failure was seen before. Doing this on strings could work, but I would like to keep the original (json serializable) values. What do you think? Thomas Güttler
Says it right in the documentation: failureException <https://docs.python.org/2/library/unittest.html#unittest.TestCase.failureExc...> This class attribute gives the exception raised by the test method. If a test framework needs to use a specialized exception, possibly to carry additional information, it must subclass this exception in order to “play fair” with the framework. The initial value of this attribute is AssertionError <https://docs.python.org/2/library/exceptions.html#exceptions.AssertionError> . On Tuesday, March 3, 2015 at 3:34:02 AM UTC-5, Thomas Güttler wrote:
Hi,
what do you think about the idea to add an optional data kwarg to unittest.failureExeption()?
Up to now a the exception class "failureException" does only get a message which is a string.
I would like to log the failed Exceptions to a structured logging back end.
Parsing the string message to extract the real value is possible, but somehow ugly and error prone.
My high level use case: Have a system (maybe ELK-Stack) to investigate if a test failure was seen before.
Doing this on strings could work, but I would like to keep the original (json serializable) values.
What do you think?
Thomas Güttler _______________________________________________ Python-ideas mailing list Python...@python.org <javascript:> https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Am 04.03.2015 um 02:45 schrieb Neil Girdhar:
Says it right in the documentation:
failureException <https://docs.python.org/2/library/unittest.html#unittest.TestCase.failureExc...>
This class attribute gives the exception raised by the test method. If a test framework needs to use a specialized exception, possibly to carry additional information, it must subclass this exception in order to “play fair” with the framework. The initial value of this attribute is AssertionError <https://docs.python.org/2/library/exceptions.html#exceptions.AssertionError>
You are right. And if you want to assertEqual(a, b) to capture a and b, you need to replace assertEqual to forward the values to your own failureException. I guess we will go this way: replace failureException and assertEqual(), assertIn(), .... No change in Python's unittest lib is needed. Thank you for your reply. Thomas Güttler -- http://www.thomas-guettler.de/
You got it. On Wed, Mar 4, 2015 at 12:55 AM, Thomas Güttler < guettliml@thomas-guettler.de> wrote:
Am 04.03.2015 um 02:45 schrieb Neil Girdhar:
Says it right in the documentation:
failureException < https://docs.python.org/2/library/unittest.html#unittest.TestCase.failureExc...
This class attribute gives the exception raised by the test method. If a test framework needs to use a specialized exception, possibly to carry additional information, it must subclass this exception in order to “play fair” with the framework. The initial value of this attribute is AssertionError < https://docs.python.org/2/library/exceptions.html#exceptions.AssertionError
You are right.
And if you want to assertEqual(a, b) to capture a and b, you need to replace assertEqual to forward the values to your own failureException.
I guess we will go this way: replace failureException and assertEqual(), assertIn(), ....
No change in Python's unittest lib is needed.
Thank you for your reply.
Thomas Güttler
participants (2)
-
Neil Girdhar -
Thomas Güttler