On Fri, Sep 24, 2021 at 8:51 PM Steven D'Aprano <st...@pearwood.info> wrote:
> > Pytest needs to take heroic measures in an import hook to re-write your > assertions to do what it does: > > Maybe a language change, with a public API for assertions, would make it > much easier and less hacky for test frameworks to do what Pytest does. > Now that's a PEP I could get behind. That's what I was getting at with asking if there were language changes that would be required to really do this right. Adding one feature to unittest doesn't seem worth it to me -- adding something to the language that makes it possible (easier) for all test frameworks to be featureful would be a fine idea. I'd love to hear what the pytest folks think of this. It wouldn't be the first time that Python added features to the language > to make it easier for third-party libraries. > agreed. > Also, Pytest only supports CPython and PyPy. > > https://pytest.org/en/6.2.x/getting-started.html Well, if the other implementations want a good test framework, that's up to them. it would be nice if better assertions was a language feature rather than > requiring heroic import hook and AST hacks to work. I suspect that the "heroic measures" pytest takes are the challenge for other implementations, but so would adding this kind of functionality to all implementations -- putting it in official Python would be essentially requiring other implementations to do so -- but the developers of those would still need to do the work. (that being said, one option I suggested what that a shiny new featureful test framework be added to the stdlib :-) ) > 2) there are a lot of things in Pytest that are very useful. > > Will they be less useful if Python gives better diagnostics on assertion > failures? > Of course not -- my point was that if you want a better test framework, you will want more than just this one feature -- and it you're going to use pytest (or something else) anyway, then why do you need this in the stdlib. > And a lot of problems with unittest. > Such as? > That's a long story that I've been meaning to write up for ages, but I'll make these few points: 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) 2) unitest is not very open to extending -- no one wants to write many more assertions, and yet, we then don't have many. 3) This is, I suppose, personal taste, but I never liked unitest, it's just too awkward and verbose for me -- the second I discovered pytest I never looked back. And I'm not alone in that. The only really unpleasant part of unittest is having to remember the > spellings of all the various `self.assertSpam...` methods. Otherwise, > it's a pretty nice framework. > The way to test Exception raising (assertRaises ?) is painful :-( But I know you have looked at the self.assertSpam methods -- why have them at all? all they do is provide a nice failure message (at least the ones I've looked at) with pytest, you don't need them at all. And there are any number of asserts that don't exist, so you have to use assertTrue, and then you don't get any benefit at all. If assertions were better, perhaps we could fix that. > yup -- then you wouldn't need any assertSpam methods -- then we could get rid of the TestCase classes, and you'd have something like pytest ;-) -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/M5YPKG3ZUGENBWEQP5N73XAXMHV5IJIB/ Code of Conduct: http://python.org/psf/codeofconduct/
