[TIP] Unittest Changes

[Andrew Bennetts]

Pekka Laukkanen wrote:
[...]
> 
> Nice that you like the idea. I've always wondered why
> 'unittest.TestCase' has those assert methods when in JUnit they are in
> separate class. 'unittest' is a pretty direct JUnit port (even
> according to its docs) so I wonder why the design has been changed.

JUnit used to provide assertions via a test case superclass too (called “Assert”
I think?).  Presumably the unittest module was inspired by that version of
JUnit.  So I don't think it's that unittest changed the design, it's that JUnit
has changed.

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.

Also, IIRC assertion methods in unittest.TestCase raise self.failureException
rather than a hard-coded exception.  This is a bit of a minor feature, but it
wouldn't be possible if the assertions weren't methods.

Perhaps it might make sense to expose the standard unittest.TestCase assertion
methods as staticmethods or classmethods?  Apparently JUnit does this.

-Andrew.