Author msuozzo
Recipients msuozzo
Date 2021-03-12.01:53:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1615514023.14.0.0477922265442.issue43478@roundup.psfhosted.org>
In-reply-to
Content
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()
    self.addCleanup(mock.patch.stopall)

  @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.
History
Date User Action Args
2021-03-12 01:53:43msuozzosetrecipients: + msuozzo
2021-03-12 01:53:43msuozzosetmessageid: <1615514023.14.0.0477922265442.issue43478@roundup.psfhosted.org>
2021-03-12 01:53:43msuozzolinkissue43478 messages
2021-03-12 01:53:42msuozzocreate