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

[Collin Winter]

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 result_set)
> + self.assertIn(func(x), result_set)
>
> 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 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 run_tests 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
>