Skip to content

take a detailed look at integration with the monkeypatch fixture #9

Open

Description

@RonnyPfannschmidt
No description provided.

Activity

  1. RonnyPfannschmidt commented on Apr 9, 2015

    @RonnyPfannschmidt
    MemberAuthor

    after some analysis i came to the conclusion that monkeypatch needs to be extended and a mock integration for pytest should never use mock.patch

  2. nicoddemus commented on Apr 9, 2015

    @nicoddemus
    Member

    Hi @RonnyPfannschmidt,

    I'm not sure what you mean, can you clarify your request a bit please? How would you like to extend monkeypatch, and what do you mean by mock integration for pytest should never use mock.patch?

  3. RonnyPfannschmidt commented on Apr 9, 2015

    @RonnyPfannschmidt
    MemberAuthor

    mock.patch maintains a custom set of own monkey-patches which is completely unaware of pytest

    monkeypatch is neither context nest-able, nor can it do partial undo

    so for a proper integration monkeypatch needs partial undo

  4. nicoddemus commented on Apr 9, 2015

    @nicoddemus
    Member

    I'm not sure what your overall object is... to integrate pytest-mock into pytest? Unify the implementations? Make pytest-mock use monkeypatch?

    While there is overlap, monkeypatch and unittest.mock are not the same. Monkeypatch does simple attribute substitution, replacing attributes and functions, while unittest.mock does that plus it provides a Mock class which you can configure to behave as another class for testing, monitor calls were made to it, etc. pytest-mock is just a convenience around the unittest.mock module for use with pytest (here's the rationale).

  5. RonnyPfannschmidt commented on Apr 9, 2015

    @RonnyPfannschmidt
    MemberAuthor

    my basic understanding is that mock.patch deals with monkeypatching mock objects into places
    so its a monkeypatching mechanism distinct from pytest monkeypatch which means monkeypatch and mock.patch do not integrate

    i'm not yet after a implementation unification, but i'd like to have things in place that taking mock support into pytest later on is straightforward and well combined

  6. nicoddemus commented on Apr 9, 2015

    @nicoddemus
    Member

    monkeypatch has an undo method, so implementing support for with statement seems straightforward to implement.

    I'm not sure what you mean by which means monkeypatch and mock.patch do not integrate, since I think this works:

    m = mock.Mock()
    monkeypatch(obj, 'attr', m)
  7. RonnyPfannschmidt commented on Apr 10, 2015

    @RonnyPfannschmidt
    MemberAuthor

    but a monkeypatch works very different from a mock.patch - for example monkeypatch lacks selective undo

  8. nicoddemus commented on Apr 10, 2015

    @nicoddemus
    Member

    That's true

  9. graingert commented on Jul 5, 2019

    @graingert
    Member

    @nicoddemus @RonnyPfannschmidt is this still blocking merging pytest-mock into pytest? With pytest 5 dropping support for platforms without unittest.mock it makes a lot of sense to have it built in

  10. nicoddemus commented on Jul 5, 2019

    @nicoddemus
    Member

    @graingert I'm not sure, because now users will have two builtin options, monkeypatch and mocker, which is confusing.

    We might think about how to integrate them instead, for example monkeypatch.mock might behave like the current mocker fixture:

    def test_foo(monkeypatch):
        monkeypatch.mock.patch('os.remove')

    Or we might decide to add patch and patch.object directly to monkeypatch:

    def test_foo(monkeypatch):
        monkeypatch.patch('os.remove')

    But actually I'm leaning towards leaving outside the core for now.

  11. graingert commented on Jul 5, 2019

    @graingert
    Member
  12. nicoddemus commented on Jul 5, 2019

    @nicoddemus
    Member

    IMO they are widely different: while tmp_path and tmpdir both provide the same temporary directory only changing the type of object returned, monkeypatch and mocker provide completely different interfaces and capabilities: monkeypatch only replaces attributes by an equivalent object, while mocker installs a MagicMock object in-place of existing attributes and adds tons of capabilities, including checking how the mock object was called.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions