python-daemon

#56 Tests: Don't mock twice
Closed by churchyard. Opened by churchyard.
churchyard/python-daemon nomock2  into  main

Download 56.patch

With Python 3.10, we see the following errors:

======================================================================
ERROR: test_acquire_uses_specified_timeout (test.test_pidfile.TimeoutPIDLockFile_TestCase)
test.test_pidfile.TimeoutPIDLockFile_TestCase.test_acquire_uses_specified_timeout
----------------------------------------------------------------------
testtools.testresult.real._StringException: Traceback (most recent call last):
  File "/usr/lib64/python3.10/unittest/mock.py", line 1367, in patched
    with self.decoration_helper(patched,
  File "/usr/lib64/python3.10/contextlib.py", line 133, in __enter__
    return next(self.gen)
  File "/usr/lib64/python3.10/unittest/mock.py", line 1349, in decoration_helper
    arg = exit_stack.enter_context(patching)
  File "/usr/lib64/python3.10/contextlib.py", line 478, in enter_context
    result = _cm_type.__enter__(cm)
  File "/usr/lib64/python3.10/unittest/mock.py", line 1529, in __enter__
    raise InvalidSpecError(
unittest.mock.InvalidSpecError: Cannot autospec attr 'acquire' from target 'PIDLockFile' as it has already been mocked out. [target=<class 'lockfile.pidlockfile.PIDLockFile'>, attr=<MagicMock name='acquire' id='139634358950000'>]
======================================================================
ERROR: test_acquire_uses_stored_timeout_by_default (test.test_pidfile.TimeoutPIDLockFile_TestCase)
test.test_pidfile.TimeoutPIDLockFile_TestCase.test_acquire_uses_stored_timeout_by_default
----------------------------------------------------------------------
testtools.testresult.real._StringException: Traceback (most recent call last):
  File "/usr/lib64/python3.10/unittest/mock.py", line 1367, in patched
    with self.decoration_helper(patched,
  File "/usr/lib64/python3.10/contextlib.py", line 133, in __enter__
    return next(self.gen)
  File "/usr/lib64/python3.10/unittest/mock.py", line 1349, in decoration_helper
    arg = exit_stack.enter_context(patching)
  File "/usr/lib64/python3.10/contextlib.py", line 478, in enter_context
    result = _cm_type.__enter__(cm)
  File "/usr/lib64/python3.10/unittest/mock.py", line 1529, in __enter__
    raise InvalidSpecError(
unittest.mock.InvalidSpecError: Cannot autospec attr 'acquire' from target 'PIDLockFile' as it has already been mocked out. [target=<class 'lockfile.pidlockfile.PIDLockFile'>, attr=<MagicMock name='acquire' id='139634358932176'>]
======================================================================
ERROR: test_calls_superclass_init (test.test_pidfile.TimeoutPIDLockFile_TestCase)
test.test_pidfile.TimeoutPIDLockFile_TestCase.test_calls_superclass_init
----------------------------------------------------------------------
testtools.testresult.real._StringException: Traceback (most recent call last):
  File "/usr/lib64/python3.10/unittest/mock.py", line 1367, in patched
    with self.decoration_helper(patched,
  File "/usr/lib64/python3.10/contextlib.py", line 133, in __enter__
    return next(self.gen)
  File "/usr/lib64/python3.10/unittest/mock.py", line 1349, in decoration_helper
    arg = exit_stack.enter_context(patching)
  File "/usr/lib64/python3.10/contextlib.py", line 478, in enter_context
    result = _cm_type.__enter__(cm)
  File "/usr/lib64/python3.10/unittest/mock.py", line 1529, in __enter__
    raise InvalidSpecError(
unittest.mock.InvalidSpecError: Cannot autospec attr '__init__' from target 'PIDLockFile' as it has already been mocked out. [target=<class 'lockfile.pidlockfile.PIDLockFile'>, attr=<MagicMock name='__init__' id='139634359084912'>]

This avoids them.

I am still about to test this in Fedora first.

I am still about to test this in Fedora first.

Works with Python 3.10 and 3.9 as well.

I'm not seeing this behaviour. Perhaps we have different lockfile library versions?

 
DEBUG util.py:446:  Installing:
DEBUG util.py:446:   python3-devel             ppc64le   3.10.0~rc1-1.fc35            build   206 k
DEBUG util.py:446:   python3-docutils          noarch    0.16-7.fc35                  build   811 k
DEBUG util.py:446:   python3-extras            noarch    1.0.0-18.fc35                build    19 k
DEBUG util.py:446:   python3-lockfile          noarch    1:0.12.2-4.fc35              build    30 k
DEBUG util.py:446:   python3-mock              noarch    3.0.5-17.fc35                build    52 k
DEBUG util.py:446:   python3-setuptools        noarch    57.4.0-1.fc35                build   928 k
DEBUG util.py:446:   python3-testscenarios     noarch    0.5.0-23.fc35                build    37 k
DEBUG util.py:446:   python3-testtools         noarch    2.5.0-2.fc35                 build   332 k

The lockfile.pidlockfile.PIDLockFile class has these attributes (in the package lockfile == 0.12.2). Is that the case for you?

When using an instance of that class in these test cases, we want those attributes mocked for this collection of test cases. Are you saying these are already mocked somewhere else?

Metadata Update from @bignose:
- Pull-request tagged with: more-info

The lockfile.pidlockfile.PIDLockFile class has these attributes (in the package lockfile == 0.12.2). Is that the case for you?

Not sure. I was having this problem 3 months ago and I fixed it with the provided patch.

When using an instance of that class in these test cases, we want those attributes mocked for this collection of test cases. Are you saying these are already mocked somewhere else?

Yes, I think they are. Let me try to figure out where.

In the decorators of the relevant tests:

  • test_acquire_uses_specified_timeout
  • test_acquire_uses_stored_timeout_by_default
  • test_calls_superclass_init

I have merged an equivalent set of changes (attributed to the author of this merge request; thanks!) in commit 0c67a3c6.
Edited by bignose

Pull-Request has been closed by bignose

Pull-Request has been closed by churchyard
Metadata
None

more-info

Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.