py.test failures in test_pytest.py

35 views
Skip to first unread message

Peter Brady

unread,
Sep 27, 2014, 6:19:21 PM9/27/14
to sy...@googlegroups.com
The failures in sympy/utilities/tests/test_pytest.py are due to a fundamental difference between bin/test and py.test (perhaps this was not a difference when the tests were written)

The failing tests:

=================================== FAILURES ===================================
___________ test_lack_of_exception_triggers_AssertionError_callable ____________

    def test_lack_of_exception_triggers_AssertionError_callable():
        try:
>           raises(Exception, lambda: 1 + 1)
E           Failed: DID NOT RAISE

sympy/utilities/tests/test_pytest.py:14: Failed
_____________ test_lack_of_exception_triggers_AssertionError_with ______________

    def test_lack_of_exception_triggers_AssertionError_with():
        try:
            with raises(Exception):
>               1 + 1
E               Failed: DID NOT RAISE

sympy/utilities/tests/test_pytest.py:39: Failed

The cause of these is that the tests are written with the assumption
 that when raises fails, it raises and AssertionError.  However py.test raises and actual Failed exception.  Here's an example

In [4]: from py.test import fail 

In [5]: raise fail()
---------------------------------------------------------------------------
Failed                                    Traceback (most recent call last)
<ipython-input-5-64d514b43c4e> in <module>()
----> 1 raise fail()

/home/peter/miniconda3/lib/python3.4/site-packages/_pytest/runner.py in fail(msg, pytrace)
    466     """
    467     __tracebackhide__ = True
--> 468     raise Failed(msg=msg, pytrace=pytrace)
    469 fail.Exception = Failed
    470 

Failed: <Failed instance>

What would be the best way to handle this?  Should we add a 'Failed` to the catch block?  It seems like a bad idea to me to catch a Fail in a test and then do something with it but maybe that's the same as catching the AssertionError?

Aaron Meurer

unread,
Sep 27, 2014, 6:39:48 PM9/27/14
to sy...@googlegroups.com
If raises() in that test is py.test's raises() when the tests are run
with py.test, then there's really no need to test it at all. We only
need to test our own raises().

Aaron Meurer
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sympy.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/b0f9af51-f164-4be2-b56c-065da0e9e6b6%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Peter Brady

unread,
Sep 27, 2014, 7:30:31 PM9/27/14
to sy...@googlegroups.com

We can certainly skip all the tests. Hopefully no other tests depend on this functionality in an important way

You received this message because you are subscribed to a topic in the Google Groups "sympy" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sympy/XrZQUPDxgIo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sympy+un...@googlegroups.com.

To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
Reply all
Reply to author
Forward
0 new messages