Getting OT here -- a full discussion of unitest is a while other topic. One I do want to have one of these days, but not now. But for closure:
> This would make assertions more useful to everyone, whatever test > framework (or no test framework at all) they use. > > > 1) Many major (and minor) projects use pytest, even though unittest is > in > > the stdlib -- why is that? And why did they even bother writing pytest > (and > > nose, back in the day) > > Good question. That was a rhetorical question,b ut I'll give the simple answer: Because a lot of people find pytest (and nose before it) some combination of easier, more comfortable and powerful. Which could be just taste, but I'd say writing pytest is an awful lot of work for just taste. And I know once I discovered it I never looked back. > My recollection from way back in Python 1.5 days was that > the vibe on comp.lang.python was all "Unit test? That's from Java, it's > unpythonic!" > Which is still very true, as Phillip J Eby famously wrote "Python is not Java". I"m not intending to criticise the decision at the time, unit testing was fairly new, and jUnit was successful. And it's not just style -- it's a fundamental approach -- jUnit was designed for a far more static, less introspectable, and more OO language than Python. > 2) unitest is not very open to extending -- no one wants to write many > more > > assertions, and yet, we then don't have many. > > o_O > > Most people complain that unittest has *too many* assert methods to > remember, not too few. I count 32 assert methods in unittest. How many > would you like? > This is exactly the problem -- no one wants hundreds of assert Methods, yet there are hundreds (thousands) of things one might want to assert. Requiring a custom assert method for each case, is, shall we say, a bit problematic. But Python is a very introspectable language -- writing a static custom assert so that you can get a nice failure message is unnecessary. For the statistics test suite, I subclassed TestCase and added a new > assert method. It's not hard to do: subclass TestCase and add some more > methods, and call `self.failureException` with your error message if the > test fails. > But why did you have to do it at all? I'm speaking from my experience -- after PEP 485 was accepted, I sat down at the PyCon sprints to add an assertClose TestCase method. The result was this: https://bugs.python.org/issue27198 In the end, the best solution was to add a new attribute to assertAlmostEqual -- which I never got around to -- I had expended my PyCon sprint time. Why didn't I pick it up later? primarily because I don't use unittest myself anyway. But that conversation sure didn't make me think that unitest was a good API, and I don't know that any of the ideas talked about there have been implemented. How do you extend pytest's special assertion handling? > you don't -- that's the entire point. back to `math.isclose()` -- you simply do: assert isclose(a, b) done. And this is what you get if it fails: > assert isclose(1.0, 1.0000001) E assert False E + where False = isclose(1.0, 1.0000001) Anyway, this isn't supposed to be a competition between test frameworks. indeed -- it's gotten OT. > > The way to test Exception raising (assertRaises ?) is painful :-( > > self.assertRaises(SomeException, callable, args, kwargs) > exactly -- painful. > Or if you prefer: > > with self.assertRaises(SomeException): > block > much better -- didn't exist when I learned unitest :-) In practice, you don't normally call most of the specialist methods > yourself. (Or at least I don't.) For example, assertEqual automatically > delegates to one of the type-specific methods (lists, multi-line > strings, tuples, etc). > ouch! Exactly the point -- that's all work that should be done, automatically by the test runner. and still we have: self.assertEqual(a, b) when we could have: assert a == b and self.assertTrue(something) rather than assert something I guess it's just taste, but my preference is clear. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MFACWOOLMCR7ICKFKARBBRDAN4DVQWRR/ Code of Conduct: http://python.org/psf/codeofconduct/
