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 Max Rothman
Recipients Max Rothman, michael.foord, rhettinger
Date 2017-07-12.15:02:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1499871751.47.0.865106683947.issue30821@psf.upfronthosting.co.za>
In-reply-to
Content
> Generally the called with asserts can only be used to match the *actual call*, and they don't determine "equivalence".

That's fair, but as unittest.mock stands now, it *does* check equivalence, but only partially, which is more confusing to users than either checking equivalence or not.

> I'm not convinced there's a massive use case - generally you want to make asserts about what your code actually does - not just check if it does something equivalent to your assert.

To me, making asserts about what your code actually does means not having tests fail because a function call switches to a set of equivalent but different arguments. As a developer, I care about the state in the parent and the state in the child, and I trust Python to work out the details in between. If Python treats two forms as equivalent, why shouldn't our tests?
History
Date User Action Args
2017-07-12 15:02:31Max Rothmansetrecipients: + Max Rothman, rhettinger, michael.foord
2017-07-12 15:02:31Max Rothmansetmessageid: <1499871751.47.0.865106683947.issue30821@psf.upfronthosting.co.za>
2017-07-12 15:02:31Max Rothmanlinkissue30821 messages
2017-07-12 15:02:31Max Rothmancreate