On Fri, Sep 24, 2021 at 10:39:32PM -0700, Christopher Barker wrote:
> Now that's a PEP I could get behind.
You mean, like this PEP? *wink*
> Adding one feature to unittest doesn't seem worth it to me
I don't think this PEP directly proposes any new features to unittest.
If it is accepted, who knows what will happen in the future?
> 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.
The stdlib has got a test or two. We can't use pytest for the stdlib
tests without making pytest a dependency and that would tie pytest to
the stdlib's release cycle.
This would make assertions more useful to everyone, whatever test
framework (or no test framework at all) they use.
> > 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)
Good question. 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!"
Besides, everyone has their own opinion on test frameworks, like web
frameworks and static code checkers. That's why there are so many of
them :-)
> 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?
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.
How do you extend pytest's special assertion handling?
Anyway, this isn't supposed to be a competition between test frameworks.
There is plenty of room in the Python ecosystem for whatever test
frameworks people want to run.
If it were a competition, they would all lose to the mighty doctest!!!
*wink*
> The way to test Exception raising (assertRaises ?) is painful :-(
self.assertRaises(SomeException, callable, args, kwargs)
Or if you prefer:
with self.assertRaises(SomeException):
block
That's almost identical to the pytest way:
https://docs.pytest.org/en/stable/reference.html#pytest-raises
(For what it's worth, both pytest and unittest introduced the context
manager form at the same time, July 2010.)
> 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.
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).
I would expect that pytest probably has similar specialised methods for
formatting type-specific exceptions, except that they are purely
internal while unittest exposes them as public methods. You say
tom-a-toe, I say tom-ar-tow.
--
Steve
_______________________________________________
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/DXP5AW5CW26XSFGDW5WEHQ5EQYDHSCH6/
Code of Conduct: http://python.org/psf/codeofconduct/
