Max Rothman added the comment: > 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? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30821> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
