Erik Bray added the comment: As I wrote (late) in the thread that shall not be named, I don't think it makes any sense to have magic assert_ methods on the Mock object. Not only does the "magic" clearly lead to too many ambiguities and other problems--I think they make less sense from an API standpoint in the first place. Typically asserting something in a test is not something an object *does*--a method. More often we as a test writers assert something *about* an object. The assertion is an external tool meant to measure and introspect things about the system under observation. In this case, although Mock is itself a testing tool, we're introspecting something about the Mock object as external observers.
Regarding the points raised about accessing other attributes like .calls and .returnvalue, and Robert's idea about set_returnvalue make me think that this could be softened somewhat. Michael is right that the assert_ problem is mostly solved now. Though I still think special casing one way of mistyping assert is the wrong way to go, and I feel like the "unsafe" option is more of kludge than anything, though it mostly gets the job done. So rather than go whole hog and say that all introspection on and interaction with the Mock object should be via functions (which I agree would weaken much of its convenience), only assertions should be via functions. As a recent user of the mock package I've found it strange, even before this controversy, that I called assert_<foo> as *methods* on the mock object itself. In all past cases when I've wanted to write special assertions for my classes I've written those as functions. In the case of Mock, using assert functions would have none of the spelling issues, and would be quite easy to drop into any test. It might also open up possibilities with duck-typing, though I'm not sure to what end yet... TL;DR, I think keep the existing assert_ methods for backward compat, including the unsafe flag and assret check, but add assert_ functions for those who would prefer such an API, and promote them in the docs as safer w.r.t. misspellings, and ensuring that your assertions are called. If it would help sweeten the deal, the assert_ functions could even come as staticmethods on the Mock class, so as to reduce the effort in writing import statements. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24651> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
