A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2008-July/081266.html below:

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

[Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement) [Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)Raymond Hettinger python at rcn.com
Wed Jul 16 22:37:16 CEST 2008
From: "Michael Foord" <fuzzyman at voidspace.org.uk>
> I assume this doesn't rule out the addition of [some of..] the new 
> convenience test methods?

In Kent Beck's book on Test Driven Development, he complains that most 
unittest implementations spawned from his original work have grown far 
too complicated and would be better served by sticking to a simple 
framework for writing and running tests.

Accordlingly, if a new test method gets added, it needs to add some 
signficant new capability.  IMO, little "convenience" methods like
self.assertLessThan() do not meet the criterion.  Polluting the module
with more methods makes it harder to fit into your head and does
little to simplify the task of writing mountains of tests.

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.


Raymond
More information about the Python-Dev mailing list

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