Pytest: Spurious unicode diffs with -v

[jacquerie]

Hi everyone,

I recently noticed spurious diffs about unicode when increasing the verbosity. Here's what I mean:

def test_u_appears_in_diff_when_the_test_fails_and_it_is_verbose():
    expected = {
        'foo': 'foo',
        'bar': 'bar',
    }
    result = {
        'foo': u'foo',
        'bar': 'not-bar',
    }

    assert expected == result

when run with $ py.test test_foo.py results in:

================================== test session starts ===================================
platform darwin -- Python 2.7.13, pytest-3.0.7, py-1.4.33, pluggy-0.4.0
rootdir: /Users/jacquerie/Code/pytest, inifile:
collected 1 items

test_foo.py F

======================================== FAILURES ========================================
______________ test_u_appears_in_diff_when_the_test_fails_and_it_is_verbose ______________

    def test_u_appears_in_diff_when_the_test_fails_and_it_is_verbose():
        expected = {
            'foo': 'foo',
            'bar': 'bar',
        }
        result = {
            'foo': u'foo',
            'bar': 'not-bar',
        }

>       assert expected == result
E       AssertionError: assert {'bar': 'bar', 'foo': 'foo'} == {'bar': 'not-bar', 'foo': 'foo'}
E         Omitting 1 identical items, use -v to show
E         Differing items:
E         {'bar': 'bar'} != {'bar': 'not-bar'}
E         Use -v to get the full diff

test_foo.py:11: AssertionError
================================ 1 failed in 0.02 seconds ================================

but, when run with $ py.test -v test_foo.py results in:

================================== test session starts ===================================
platform darwin -- Python 2.7.13, pytest-3.0.7, py-1.4.33, pluggy-0.4.0 -- /Users/jacquerie/.virtualenvs/pytest/bin/python2.7
cachedir: .cache
rootdir: /Users/jacquerie/Code/pytest, inifile:
collected 1 items

test_foo.py::test_u_appears_in_diff_when_the_test_fails_and_it_is_verbose FAILED

======================================== FAILURES ========================================
______________ test_u_appears_in_diff_when_the_test_fails_and_it_is_verbose ______________

    def test_u_appears_in_diff_when_the_test_fails_and_it_is_verbose():
        expected = {
            'foo': 'foo',
            'bar': 'bar',
        }
        result = {
            'foo': u'foo',
            'bar': 'not-bar',
        }

>       assert expected == result
E       AssertionError: assert {'bar': 'bar', 'foo': 'foo'} == {'bar': 'not-bar', 'foo': 'foo'}
E         Common items:
E         {'foo': 'foo'}
E         Differing items:
E         {'bar': 'bar'} != {'bar': 'not-bar'}
E         Full diff:
E         - {'bar': 'bar', 'foo': 'foo'}
E         + {'bar': 'not-bar', 'foo': u'foo'}
E         ?          ++++             +

test_foo.py:11: AssertionError
================================ 1 failed in 0.03 seconds ================================

(note the spurious extra diff on the u).

Is there something I can do about this? This example is "nice", in the sense that the dictionaries that I am typically comparing have tens of keys, so using -v or even -vv is necessary for me, but I would like to avoid the noise of the extra diffs on the us.

This is happening to me with pytest==3.0.7 on Mac OS X, while a colleague reports it happening on Linux as well. pip list is from an empty virtual env after I've run pip install pytest, where I already see this problem:

$ pip list
appdirs (1.4.3)
packaging (16.8)
pip (9.0.1)
py (1.4.33)
pyparsing (2.2.0)
pytest (3.0.7)
setuptools (34.3.2)
six (1.10.0)
wheel (0.30.0a0)

[nicoddemus]

Indeed the problem here is that pytest does text diff between the objects. We should probably discuss if this approach is feasible or not.

[cprice404]

Running into this same issue, and it makes debugging tests that compare large nested maps pretty painful.

[asottile]

hello, first off thank you for the issue!

python 2.x support has ended for pytest core.

we've decided in #7296 to close the python-2-specific issues to free up some space in our backlog. however, in accordance to our python 2.7 and 3.4 support community patches will still be accepted to the 4.6 series to fix bugs for python 2. (so if this issue is important to you and you have a patch to fix it, feel free to make a PR targeting the 4.6.x branch despite this ticket being closed).