Incorrect behavior for pathlib.Path.resolve() when path does not exist

[apt-itude]

In the following test suite, the test that does not use the fs fixture succeeds while the test that does use the fs fixture fails:

import pathlib

import pytest


def test_pathlib_resolve_without_fs():
    path = pathlib.Path('/var/foo/bar/baz')

    assert path.resolve() == path


@pytest.mark.usefixtures('fs')
def test_pathlib_resolve_with_fs():
    path = pathlib.Path('/var/foo/bar/baz')

    assert path.resolve() == path

Here is a snippet of the results:

===================================================== FAILURES =====================================================
___________________________________________ test_pathlib_resolve_with_fs ___________________________________________

>   ???
E   AssertionError: assert PosixPath('/var') == PosixPath('/var/foo/bar/baz')
E    +  where PosixPath('/var') = <bound method FakePath.resolve of PosixPath('/var/foo/bar/baz')>()
E    +    where <bound method FakePath.resolve of PosixPath('/var/foo/bar/baz')> = PosixPath('/var/foo/bar/baz').resolve

From the documentation (https://docs.python.org/3/library/pathlib.html#pathlib.Path.resolve):

If strict is False, the path is resolved as far as possible and any remainder is appended without checking whether it exists.

A similar bug existed in Python itself, but was fixed in version 3.6.2.

Environment

OS: CentOS Linux release 7.3.1611 (Core)
Python: 3.6.5
pyfakefs: 3.4.1

[mrbean-bremen]

Thanks for the report - I will have a look!

[mrbean-bremen]

Interestingly enough, there had been a test in place for this, but it had an error - instead of the intended assertEqual it used assertTrue to check for the resolved name. Urgh... Together with the fact that the implementation of resolve was directly taken from Python (which was buggy for Python at the time) this caused the problem.

[apt-itude]

Thanks for being so responsive!