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

Ben Finney ben+python at benfinney.id.au
Thu Jul 17 03:28:17 CEST 2008

Andrew Bennetts <andrew-pythondev at puzzling.org> writes:

Ben Finney wrote: > Andrew Bennetts <andrew-pythondev at puzzling.org> writes: > > > This one is easily solved by making assertRaises return the > > exception it caught. > > That breaks one simple feature of the unittest API: that all the > test methods will either raise a failure asertion, or return None.

How is returning None a feature?

A test method having exactly one meaning is a feature. If it's consistent across the API, the API retains a level of simplicity.

I've never seen code that somehow depends on assertRaises returning None.

I hope never to see code depending on methods named "assert*" returning something, instead of only asserting a condition.

Further, I have lots of evidence that in practice returning the exception instance from assertRaises is not a problem, and is in fact quite useful.

I'm sure it's useful. I don't think it belongs in the return value of such a method.

I'd quote “Practicality beats purity”, but I'm not even sure if it is purity that you have in mind.

Close: I'm interested in keeping camel's noses out of tents.

-- \ “Laugh and the world laughs with you; snore and you sleep | `\ alone.” —anonymous | o_) | Ben Finney

More information about the Python-Dev mailing list