[issue2578] additional unittest type equality methods

Gregory P. Smith report at bugs.python.org
Tue Mar 31 18:37:06 CEST 2009


Gregory P. Smith <greg at krypto.org> added the comment:

Reviewers: fuzzyman, GvR,

http://codereview.appspot.com/32080/diff/13/1006
File Doc/library/unittest.rst (right):

http://codereview.appspot.com/32080/diff/13/1006#newcode611
Line 611: assertTrue(expr[, msg])
On 2009/03/31 15:01:06, GvR wrote:
> Make assertTrue the first/preferred/recommended spelling.

Done.

http://codereview.appspot.com/32080/diff/13/1006#newcode623
Line 623: :const:`None`.  Note that using :meth:`failUnlessEqual`
improves upon
On 2009/03/31 15:01:06, GvR wrote:
> failUnlessEqal -> assertEqual

Done.

http://codereview.appspot.com/32080/diff/13/1006#newcode624
Line 624: doing the comparison as the first parameter to
:meth:`failUnless`: the
On 2009/03/31 15:01:06, GvR wrote:
> failUnless -> assertTrue

> (This kind of change may have to be done throughout.)

Done.

http://codereview.appspot.com/32080/diff/13/1010
File Lib/test/test_unittest.py (right):

http://codereview.appspot.com/32080/diff/13/1010#newcode75
Line 75: self.fail("%s and %s do not hash equal" % (obj_1, obj_2))
On 2009/03/31 15:01:06, GvR wrote:
> maybe better %r and %r ?

Done.

http://codereview.appspot.com/32080/diff/13/1010#newcode84
Line 84: self.fail("%s and %s hash equal, but shouldn't" %
On 2009/03/31 15:01:06, GvR wrote:
> ditto?

Done.

http://codereview.appspot.com/32080/diff/13/1010#newcode2313
Line 2313: self.assertRaises(self.failureException, self.assertIn,
'elephant', animals)
On 2009/03/31 15:01:06, GvR wrote:
> lin too long

Done.

http://codereview.appspot.com/32080/diff/13/1010#newcode2317
Line 2317: self.assertRaises(self.failureException, self.assertNotIn,
'cow', animals)
On 2009/03/31 15:01:06, GvR wrote:
> linr too long

Done.

http://codereview.appspot.com/32080/diff/13/1007
File Lib/unittest.py (right):

http://codereview.appspot.com/32080/diff/13/1007#newcode257
Line 257: class AssertRaisesContext(object):
On 2009/03/31 15:01:06, GvR wrote:
> While you're at it, can you add a docstring?

Done.  We also decided that this should be private so I've added an _.

http://codereview.appspot.com/32080/diff/13/1007#newcode332
Line 332: # Map types to custom assertEquals functions that will compare
On 2009/03/31 15:01:06, GvR wrote:
> assertEquals -> assertEqual

Done.

http://codereview.appspot.com/32080/diff/13/1007#newcode512
Line 512: # should use their type specific assertSpamEquals method to
compare
On 2009/03/31 15:01:06, GvR wrote:
> assertSpamEqual

Done.

http://codereview.appspot.com/32080/diff/13/1007#newcode521
Line 521: def _baseAssertEquals(self, first, second, msg=None):
On 2009/03/31 15:01:06, GvR wrote:
> Mind dropping the trailing 's'?

Done.

http://codereview.appspot.com/32080/diff/13/1007#newcode526
Line 526: def failUnlessEqual(self, first, second, msg=None):
On 2009/03/31 15:01:06, GvR wrote:
> We had talked about making the 'def' define the recommended name, e.g.
> assertNotEqual, and using aliases to keep the other names.  Do you
want to do
> that at the same time as this change or in a separate one?

Yes I'm going to do that in the next revision immediately after this
one.

http://codereview.appspot.com/32080/diff/13/1007#newcode581
Line 581: def assertSequenceEquals(self, seq1, seq2, msg=None,
seq_type=None):
On 2009/03/31 15:01:06, GvR wrote:
> Drop the trailing 's' in the name?

Done.

Description:
http://bugs.python.org/issue2578 - additional unittest type specific
equality methods that print useful error messages and type introspection
within assertEqual to automatically use them when deemed appropriate.

Please review this at http://codereview.appspot.com/32080

Affected files:
   M     Doc/library/unittest.rst
   M     Lib/test/test_gc.py
   M     Lib/test/test_struct.py
   M     Lib/test/test_unittest.py
   M     Lib/unittest.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2578>
_______________________________________


More information about the Python-bugs-list mailing list