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

[Ben Finney]

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

> Ben Finney wrote:
> > Andrew Bennetts <andrew-pythondev at puzzling.org> writes:
> [...]
> > > 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.
> 
> Your reply makes no sense to me.
> 
> I am proposing that it should have exactly one meaning.

You're proposing to give "assertRaises" a *new* meaning, without
changing its name to "assertRaisesAndReturnExceptionIfRaises".

The function name should say *all* that the function does, from the
perspective of the caller. If you're proposing to have the function do
extra things that aren't part of what the name says it will do, then
that deserves either a rename or a new function.

> It seems you have a different meaning of “meaning” than I do,
> which suggests that this conversation is doomed. I hope I don't
> sound hostile, I'm just bewildered. Your argument isn't making any
> sense to me.

I hope that clarifies it. The name of a thing, in Python especially,
is very important; in an API, even more so. If the behaviour of the
function isn't matched by the name, it's a poorly chosen name, a
poorly designed function, or both.

> I can of course keep using TestCase subclasses that override
> assertRaises to be more useful.

Why would you override that function to do something not described by
the name, instead of simply adding a new method that performs this
extra task you want performed?

-- 
 \         “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\         Brain, but isn't a cucumber that small called a gherkin?” |
_o__)                                           —_Pinky and The Brain_ |
Ben Finney