[Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement) (original) (raw)
Collin Winter collinw at gmail.com
Thu Jul 17 00:16:38 CEST 2008
- Previous message: [Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)
- Next message: [Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wed, Jul 16, 2008 at 2:03 PM, Raymond Hettinger <python at rcn.com> wrote:
If some people want to proceed down the path of "useful additions", I challenge them to think bigger. Give me some test methods that improve my life. Don't give me thirty ways to spell something I can already do. From: "Michael Foord" <fuzzyman at voidspace.org.uk>
I assert that... the following changes do meet those conditions: assertRaisesWithMessage . . . Changes to assertEquals so that the failure messages are more useful ... assertIn / assertNotIn I use very regularly for collection membership - self.assert(func(x) in resultset) + self.assertIn(func(x), resultset) Yawn. The gain is zero. Actually, it's negative because the second doesn't read as nicely as the pure python expression.
It's only negative if the method doesn't do anything special. For example, an assertListEqual() method can tell you how the lists differ, which the pure Python expression can't -- all the Python expression can say is "yes" or "no". We have methods like this at work and they're very useful.
That said, I see no reason why these things have to be methods. The self. method boilerplate is cluttering line-noise in this case. I can easily imagine a module of nothing but comparison functions.
Collin Winter
Think bigger! No fat APIs. Do something cool! Checkout the dynamic test creation in testdecimal to see if it can be generalized. Give me some cool test runners. Maybe find a way to automatically launch pdb or to dump the locals variables at the time of failure. Maybe move the "test*.py" search into the unittest module.
We want small and powerful. The api for TestCase instances is already way too fat. See an old discussion on the subject at: http://bugs.python.org/issue2578
The runtests function for running collections of tests. Almost every project I've worked on has had an ad-hoc imnplementation of this, collecting test modules and turning them into a suitable collection for use with unittest. Now, that's more like it. Propose more cool stuff like this and the module really will be improved. assertIs / assertIsNot also sounds good, but is not something I would miss if they weren't added. Doh! We're back to replacing clean expressions using pure python syntax with a method name equivalent. That's a step backwards. Raymond
Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/collinw%40gmail.com
- Previous message: [Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)
- Next message: [Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]