>> 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.
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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4