This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author msuozzo
Recipients msuozzo
Date 2021-03-12.01:53:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
An unfortunately common pattern over large codebases of Python tests is for spec'd Mock instances to be provided with Mock objects as their specs. This gives the false sense that a spec constraint is being applied when, in fact, nothing will be disallowed.

The two most frequently observed occurrences of this anti-pattern are as follows:

* Re-patching an existing autospec.

  def setUp(self):
    mock.patch.object(mod, 'Klass', autospec=True).start()

  @mock.patch.object(mod, 'Klass', autospec=True)  # :(
  def testFoo(self, mock_klass):
    # mod.Klass has no effective spec.

* Deriving an autospec Mock from an already-mocked object

  def setUp(self):
    mock.patch.object(mod, 'Klass').start()
    mock_klass = mock.create_autospec(mod.Klass)  # :(
    # mock_klass has no effective spec

This is fairly easy to detect using _is_instance_mock at patch time however it can break existing tests.

I have a patch ready and it seems like this error case is not frequent enough that it would be disruptive to address.

Another option would be add it as a warning for a version e.g. 3.10 and then potentially make it a breaking change in 3.11. However considering this is a test-only change with a fairly clear path to fix it, that might be overly cautious.
Date User Action Args
2021-03-12 01:53:43msuozzosetrecipients: + msuozzo
2021-03-12 01:53:43msuozzosetmessageid: <>
2021-03-12 01:53:43msuozzolinkissue43478 messages
2021-03-12 01:53:42msuozzocreate