How can I hide my stack frames in a TestCase subclass?

Discussion in 'Python' started by David Banks, Oct 4, 2012.

  1. David Banks

    David Banks Guest

    I want to add a custom assert method to a TestCase subclass. I tried to
    copy my implementation from the unittest module so that it would match
    the behaviour of the regular TestCase as closely as possible. (I would
    prefer to just delegate to self.assertEqual() but this causes even more
    backtrace noise, see below.) The unittest module seems to automatically
    hide some internal details of its implementation when reporting failed
    assertions.

    import unittest

    class MyTestCase(unittest.TestCase):
    def assertLengthIsOne(self, sequence, msg=None):
    if len(sequence) != 1:
    msg = self._formatMessage(msg, "length is not one")
    raise self.failureException(msg)

    class TestFoo(MyTestCase):
    seq = (1, 2, 3, 4, 5)

    def test_stock_unittest_assertion(self):
    self.assertEqual(len(self.seq), 1)

    def test_custom_assertion(self):
    self.assertLengthIsOne(self.seq)


    unittest.main()

    The output of this is as such:

    amoe@vuurvlieg $ python unittest-demo.py
    FF
    ======================================================================
    FAIL: test_custom_assertion (__main__.TestFoo)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
    File "unittest-demo.py", line 16, in test_custom_assertion
    self.assertLengthIsOne(self.seq)
    File "unittest-demo.py", line 7, in assertLengthIsOne
    raise self.failureException(msg)
    AssertionError: length is not one

    ======================================================================
    FAIL: test_stock_unittest_assertion (__main__.TestFoo)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
    File "unittest-demo.py", line 13, in test_stock_unittest_assertion
    self.assertEqual(len(self.seq), 1)
    AssertionError: 5 != 1

    ----------------------------------------------------------------------
    Ran 2 tests in 0.000s

    FAILED (failures=2)

    Note that the custom assert method causes a stack trace with two frames,
    one inside the method itself, whereas the stock unittest method only has
    one frame, the relevant line in the user's code. How can I apply this
    frame-hiding behaviour to my own method?
     
    David Banks, Oct 4, 2012
    #1
    1. Advertising

  2. David Banks

    Peter Otten Guest

    David Banks wrote:

    > I want to add a custom assert method to a TestCase subclass. I tried to
    > copy my implementation from the unittest module so that it would match
    > the behaviour of the regular TestCase as closely as possible. (I would
    > prefer to just delegate to self.assertEqual() but this causes even more
    > backtrace noise, see below.) The unittest module seems to automatically
    > hide some internal details of its implementation when reporting failed
    > assertions.
    >
    > import unittest
    >
    > class MyTestCase(unittest.TestCase):
    > def assertLengthIsOne(self, sequence, msg=None):
    > if len(sequence) != 1:
    > msg = self._formatMessage(msg, "length is not one")
    > raise self.failureException(msg)
    >
    > class TestFoo(MyTestCase):
    > seq = (1, 2, 3, 4, 5)
    >
    > def test_stock_unittest_assertion(self):
    > self.assertEqual(len(self.seq), 1)
    >
    > def test_custom_assertion(self):
    > self.assertLengthIsOne(self.seq)
    >
    >
    > unittest.main()
    >
    > The output of this is as such:
    >
    > amoe@vuurvlieg $ python unittest-demo.py
    > FF
    > ======================================================================
    > FAIL: test_custom_assertion (__main__.TestFoo)
    > ----------------------------------------------------------------------
    > Traceback (most recent call last):
    > File "unittest-demo.py", line 16, in test_custom_assertion
    > self.assertLengthIsOne(self.seq)
    > File "unittest-demo.py", line 7, in assertLengthIsOne
    > raise self.failureException(msg)
    > AssertionError: length is not one
    >
    > ======================================================================
    > FAIL: test_stock_unittest_assertion (__main__.TestFoo)
    > ----------------------------------------------------------------------
    > Traceback (most recent call last):
    > File "unittest-demo.py", line 13, in test_stock_unittest_assertion
    > self.assertEqual(len(self.seq), 1)
    > AssertionError: 5 != 1
    >
    > ----------------------------------------------------------------------
    > Ran 2 tests in 0.000s
    >
    > FAILED (failures=2)
    >
    > Note that the custom assert method causes a stack trace with two frames,
    > one inside the method itself, whereas the stock unittest method only has
    > one frame, the relevant line in the user's code. How can I apply this
    > frame-hiding behaviour to my own method?


    Move MyTestCase in a separate module and define a global variable

    __unittest = True

    $ cat mytestcase.py
    import unittest

    __unittest = True

    class MyTestCase(unittest.TestCase):
    def assertLengthIsOne(self, sequence, msg=None):
    if len(sequence) != 1:
    msg = self._formatMessage(msg, "length is not one")
    raise self.failureException(msg)

    $ cat mytestcase_demo.py
    import unittest
    from mytestcase import MyTestCase

    class TestFoo(MyTestCase):
    seq = (1, 2, 3, 4, 5)

    def test_stock_unittest_assertion(self):
    self.assertEqual(len(self.seq), 1)

    def test_custom_assertion(self):
    self.assertLengthIsOne(self.seq)

    if __name__ == "__main__":
    unittest.main()

    $ python mytestcase_demo.py
    FF
    ======================================================================
    FAIL: test_custom_assertion (__main__.TestFoo)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
    File "mytestcase_demo.py", line 11, in test_custom_assertion
    self.assertLengthIsOne(self.seq)
    AssertionError: length is not one

    ======================================================================
    FAIL: test_stock_unittest_assertion (__main__.TestFoo)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
    File "mytestcase_demo.py", line 8, in test_stock_unittest_assertion
    self.assertEqual(len(self.seq), 1)
    AssertionError: 5 != 1

    ----------------------------------------------------------------------
    Ran 2 tests in 0.000s

    FAILED (failures=2)
    $
     
    Peter Otten, Oct 4, 2012
    #2
    1. Advertising

  3. Peter Otten scripsit :

    > David Banks wrote:
    >
    >> Note that the custom assert method causes a stack trace with two frames,
    >> one inside the method itself, whereas the stock unittest method only has
    >> one frame, the relevant line in the user's code. How can I apply this
    >> frame-hiding behaviour to my own method?

    >
    > Move MyTestCase in a separate module and define a global variable
    >
    > __unittest = True
    >

    Hum, is it documented somewhere? I can't find it in the doc. Also, I'm
    curious to know what kind of magic it's using.

    --
    Manuel Pégourié-Gonnard - http://people.math.jussieu.fr/~mpg/
     
    Manuel Pégourié-Gonnard, Oct 5, 2012
    #3
  4. David Banks

    Peter Otten Guest

    Manuel Pégourié-Gonnard wrote:

    > Peter Otten scripsit :
    >
    >> David Banks wrote:
    >>
    >>> Note that the custom assert method causes a stack trace with two frames,
    >>> one inside the method itself, whereas the stock unittest method only has
    >>> one frame, the relevant line in the user's code. How can I apply this
    >>> frame-hiding behaviour to my own method?

    >>
    >> Move MyTestCase in a separate module and define a global variable
    >>
    >> __unittest = True
    >>

    > Hum, is it documented somewhere? I can't find it in the doc. Also, I'm
    > curious to know what kind of magic it's using.


    I took advantage of the fact that Python is open source and had a look into
    the source code ;)

    $ cd /usr/lib/python2.7/unittest
    $ grep frame *.py -C2
    ....
    result.py-
    result.py- def _is_relevant_tb_level(self, tb):
    result.py: return '__unittest' in tb.tb_frame.f_globals
    result.py-
    ....

    $ grep _is_relevant_tb_level *.py -C5
    result.py-
    result.py- def _exc_info_to_string(self, err, test):
    result.py- """Converts a sys.exc_info()-style tuple of values into a
    string."""
    result.py- exctype, value, tb = err
    result.py- # Skip test runner traceback levels
    result.py: while tb and self._is_relevant_tb_level(tb):
    result.py- tb = tb.tb_next
    result.py-
    ....

    And so on. I actually used an editor, not grep -- but you get the idea.
     
    Peter Otten, Oct 5, 2012
    #4
  5. Peter Otten scripsit :

    > Manuel Pégourié-Gonnard wrote:
    >
    >> Peter Otten scripsit :
    >>
    >>> __unittest = True
    >>>

    >> Hum, is it documented somewhere? I can't find it in the doc. Also, I'm
    >> curious to know what kind of magic it's using.

    >
    > I took advantage of the fact that Python is open source and had a look into
    > the source code ;)
    >

    Fair enough.

    However, there was an implied question in the "documented" part: can
    we rely on it? Isn't it considered an implementation detail (names
    starting with underscores)?

    > $ cd /usr/lib/python2.7/unittest
    > $ grep frame *.py -C2
    > ...
    > result.py-
    > result.py- def _is_relevant_tb_level(self, tb):
    > result.py: return '__unittest' in tb.tb_frame.f_globals
    > result.py-
    > ...
    >
    > $ grep _is_relevant_tb_level *.py -C5
    > result.py-
    > result.py- def _exc_info_to_string(self, err, test):
    > result.py- """Converts a sys.exc_info()-style tuple of values into a
    > string."""
    > result.py- exctype, value, tb = err
    > result.py- # Skip test runner traceback levels
    > result.py: while tb and self._is_relevant_tb_level(tb):
    > result.py- tb = tb.tb_next
    > result.py-
    > ...
    >
    > And so on. I actually used an editor, not grep -- but you get the idea.


    Sure, thanks.

    --
    Manuel Pégourié-Gonnard - http://people.math.jussieu.fr/~mpg/
     
    Manuel Pégourié-Gonnard, Oct 5, 2012
    #5
  6. David Banks

    Peter Otten Guest

    Manuel Pégourié-Gonnard wrote:

    > However, there was an implied question in the "documented" part: can
    > we rely on it? Isn't it considered an implementation detail (names
    > starting with underscores)?


    "Not documented" was my implied answer.

    I think you have a valid use case, though, so you could make a feature
    request for an official way to hide stack frames on the bugtracker
    http://bugs.python.org or the python-ideas mailing list.
     
    Peter Otten, Oct 5, 2012
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jstorta
    Replies:
    3
    Views:
    475
    jstorta
    Feb 20, 2006
  2. Scott
    Replies:
    1
    Views:
    144
    Timothy Hunter
    Aug 20, 2005
  3. S.Volkov
    Replies:
    2
    Views:
    242
    S.Volkov
    Mar 12, 2006
  4. Trans
    Replies:
    8
    Views:
    352
    Robert Klemme
    Oct 23, 2008
  5. Marek Mänd
    Replies:
    5
    Views:
    219
    Thomas 'PointedEars' Lahn
    Jun 27, 2004
Loading...

Share This Page