[Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement) (original) (raw)

Raymond Hettinger python at rcn.com
Wed Jul 16 23:03:29 CEST 2008

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

Yawn. The gain is zero. Actually, it's negative because the second doesn't read as nicely as the pure python expression.

Think bigger! No fat APIs. Do something cool! Checkout the dynamic test creation in test_decimal 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

More information about the Python-Dev mailing list