[TIP] Unittest Changes
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
> 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.
More information about the testing-in-python