Skip to content

Documentation for asserting values of unittest.mock.Mock.call_args_list #91365

Closed as not planned

Description

@himkt
mannequin
BPO 47209
Nosy @himkt

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2022-04-04.03:24:22.676>
labels = ['3.11', 'type-bug', 'docs']
title = 'Documentation for asserting values of `unittest.mock.Mock.call_args_list`'
updated_at = <Date 2022-04-04.05:58:03.586>
user = 'https://github.com/himkt'

bugs.python.org fields:

activity = <Date 2022-04-04.05:58:03.586>
actor = 'himkt'
assignee = 'docs@python'
closed = False
closed_date = None
closer = None
components = ['Documentation']
creation = <Date 2022-04-04.03:24:22.676>
creator = 'himkt'
dependencies = []
files = []
hgrepos = []
issue_num = 47209
keywords = []
message_count = 3.0
messages = ['416650', '416652', '416653']
nosy_count = 2.0
nosy_names = ['docs@python', 'himkt']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue47209'
versions = ['Python 3.11']

Activity

  1. himkt commented on Apr 4, 2022

    himktmannequin
    MannequinAuthor

    Currently documentation says we can check call_args_list by providing a list of tuples of arguments.

    >>> expected = [(), ((3, 4),), ({'key': 'fish', 'next': 'w00t!'},)]
    >>> mock.call_args_list == expected
    True
    

    (from https://docs.python.org/3.11/library/unittest.mock.html#unittest.mock.Mock.call_args_list)

    However, I think we have to wrap all arguments with call.
    I'd happy to send a patch if it should be fixed.

    ### Reproduce:

    import time
    from unittest.mock import call
    from unittest.mock import patch
    
    
    with patch("time.sleep") as mock_obj:
        time.sleep(1)
        time.sleep(2)
    
        print("mock_obj.call_args_list")
        print(mock_obj.call_args_list)
    
        print("mock_obj.call_args_list == [(1,), (2,)]")
        print(mock_obj.call_args_list == [(1,), (2,)])
        print("mock_obj.call_args_list == [call(1,), call(2,)]")
        print(mock_obj.call_args_list == [call(1,), call(2,)])
    
    > python demo.py                                                                                                                                                             2022-04-04 12:03:18
    mock_obj.call_args_list
    [call(1), call(2)]
    mock_obj.call_args_list == [(1,), (2,)]
    False
    mock_obj.call_args_list == [call(1,), call(2,)]
    True
    

    ### Links

  2. added
    docsDocumentation in the Doc dir
    type-bugAn unexpected behavior, bug, or error
    3.11only security fixes
    on Apr 4, 2022
  3. added
    docsDocumentation in the Doc dir
    type-bugAn unexpected behavior, bug, or error
    on Apr 4, 2022
  4. himkt commented on Apr 4, 2022

    himktmannequin
    MannequinAuthor

    So sorry, documentation is not wrong.
    It only need to wrap an argument when it is a singular value.

    But I'm still wondering if we can unify documentation to wrap call (e.g. https://github.com/himkt/cpython/blob/main/Doc/library/unittest.mock-examples.rst#checking-multiple-calls-with-mock does it).

  5. himkt commented on Apr 4, 2022

    himktmannequin
    MannequinAuthor

    It only need to wrap an argument when it is a singular value.

    It is also wrong..., sorry.
    To compare a single value, I should have passed a tuple of tuples.

    > python demo.py                                                                                                                                                             2022-04-04 14:56:41
    mock_obj.call_args_list
    [call(1), call(2)]
    mock_obj.call_args_list == [(1,), (2,)]
    False
    mock_obj.call_args_list == [call(1,), call(2,)]
    True
    mock_obj.call_args_list == [((1,),), ((2,),)]
    True
    
  6. transferred this issue fromon Apr 10, 2022
  7. tirkarthi commented on May 21, 2022

    @tirkarthi
    Member

    Just to add call objects themselves are tuples. The docstring of _Call has similar examples

    cpython/Lib/unittest/mock.py

    Lines 2418 to 2436 in 2fadde7

    class _Call(tuple):
    """
    A tuple for holding the results of a call to a mock, either in the form
    `(args, kwargs)` or `(name, args, kwargs)`.
    If args or kwargs are empty then a call tuple will compare equal to
    a tuple without those values. This makes comparisons less verbose::
    _Call(('name', (), {})) == ('name',)
    _Call(('name', (1,), {})) == ('name', (1,))
    _Call(((), {'a': 'b'})) == ({'a': 'b'},)
    The `_Call` object provides a useful shortcut for comparing with call::
    _Call(((1, 2), {'a': 3})) == call(1, 2, a=3)
    _Call(('foo', (1, 2), {'a': 3})) == call.foo(1, 2, a=3)
    If the _Call has no name then it will match any name.
    """

  8. slateny commented on Sep 9, 2022

    @slateny
    Contributor

    @himkt Do you still think the docs need clarification or are fine as-is?

  9. himkt commented on Sep 9, 2022

    @himkt
    Author

    Sorry, I just noticed the thread is tracked here. Yeah I think the docs are fine as-is. Thank you for pinning.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.11only security fixesdocsDocumentation in the Doc dirtype-bugAn unexpected behavior, bug, or error

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions