[TIP] Unittest Changes

Andrew Bennetts andrew-tip at puzzling.org
Mon Jul 28 16:46:15 PDT 2008


Pekka Laukkanen wrote:
> 2008/7/22 Andrew Bennetts <andrew-tip at puzzling.org>:
[...]
> > Personally, I'm satisfied with the status quo (providing assertion methods via
> > TestCases).  It's pretty common to implement custom assertion methods, and the
> > natural home for these is usually on a TestCase subclass that I already have
> > anyway.  It would feel a little weird to have a mix of "asserts.equals(...)" and
> > e.g.  "self.assertAncestryEqual(...)", rather than consistently using "self."
> > for all asserts.
> 
> If the old API is not changed (I don't propose that) you can keep
> using this approach. Alternatively you can create your own asserts

That violates “There should be one-- and preferably only one --obvious way to do
it.”

> module and have all asserts there (even standard asserts if you do
> 'from asserts import *' in the beginning of that module). Personally
> I'd prefer separating asserts from other logic but that's mainly
> matter of taste.

Putting custom assertion methods in a module wouldn't work for all asserts.
It's not unusual for a custom assertion to use other test helpers that operate
on the test fixture accessed via “self”.

[...]
> > Perhaps it might make sense to expose the standard unittest.TestCase assertion
> > methods as staticmethods or classmethods?  Apparently JUnit does this.
> 
> I would found using 'unittest.TestCase.assertEqual' somewhat
> cumbersome compared to 'asserts.assert_equal'. Additionally, you
> couldn't import only some of those static methods similarly as you can
> import only certain functions from a module. At least I also totally
> agree with http://dirtsimple.org/2004/12/python-is-not-java.html that
> "the idiomatic translation of a Java static method is usually a
> module-level function, not a classmethod or staticmethod."

That's true.  I still don't find the arguments for providing asserts separately
to TestCase convincing, but obviously tastes vary.

-Andrew.




More information about the testing-in-python mailing list