Repository navigation
additional unittest type equality methods #46830
Description
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/gpshead'
closed_at = <Date 2009-04-05.19:22:41.257>
created_at = <Date 2008-04-08.01:01:25.325>
labels = ['type-feature', 'library']
title = 'additional unittest type equality methods'
updated_at = <Date 2011-03-16.03:42:27.279>
user = 'https://github.com/benjaminp'bugs.python.org fields:
activity = <Date 2011-03-16.03:42:27.279>
actor = 'ezio.melotti'
assignee = 'gregory.p.smith'
closed = True
closed_date = <Date 2009-04-05.19:22:41.257>
closer = 'michael.foord'
components = ['Library (Lib)']
creation = <Date 2008-04-08.01:01:25.325>
creator = 'benjamin.peterson'
dependencies = []
files = ['13488', '13510', '13613', '13614']
hgrepos = []
issue_num = 2578
keywords = ['patch']
message_count = 68.0
messages = ['65132', '65142', '65145', '65146', '65148', '65150', '65154', '65240', '65244', '70982', '80748', '80773', '80774', '84342', '84353', '84359', '84360', '84379', '84413', '84426', '84427', '84430', '84431', '84432', '84619', '84622', '84625', '84627', '84633', '84650', '84757', '84759', '84795', '84829', '84831', '84836', '84838', '84861', '84866', '84885', '84973', '85047', '85107', '85111', '85116', '85199', '85221', '85242', '85243', '85247', '85249', '85269', '85274', '85275', '85317', '85326', '85327', '85399', '85400', '85401', '85405', '85406', '85416', '85422', '85431', '85442', '85556', '85560']
nosy_count = 11.0
nosy_names = ['skip.montanaro', 'rhettinger', 'gregory.p.smith', 'ncoghlan', 'pitrou', 'giampaolo.rodola', 'pupeno', 'benjamin.peterson', 'gpolo', 'ezio.melotti', 'michael.foord']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue2578'
versions = ['Python 3.1']
Activity
benjaminp commentedon Apr 8, 2008
unittest has many redundant APIs (eg. failIf and assertFalse) which can
be phased out in 3.x. We may also want to change the actually methods so
they really do what they say:
rather than
gvanrossum commentedon Apr 8, 2008
My plan:
rhettinger commentedon Apr 8, 2008
In a separate bug report, Steve Purcell indicated that he was taking
the module in the opposite direction and adding more redundancy in an
effort to fully match the J-Unit API.
gvanrossum commentedon Apr 8, 2008
I'm all for adding new APIs that provide new functionality (we have a
few at Google that we really should contribute).
I'm not for having several aliases for the same functionality; it maybe
the JUnit way but Python's unittest.py is not JUnit not does it strive
for 100% JUnit compatibility -- the languages just are to different.
What's the bug# for Steve's proposal?
rhettinger commentedon Apr 8, 2008
See http://bugs.python.org/issue2249 for discussion.
Personally, I prefer minimalism and would like the API thinned
considerably. Also, I don't think all of the classes should be
exposed. AFAICT, nobody cares about test suite objects, test result
objects, and test loader objects. These are really artifiacts of an
implementation originally designed to demonstrate how a unittest suite
could be implemented.
In Kent Beck's book on Test Driven Development, he complains that most
unittest implementations spawned from his original work have grown far
too complicated and would be better served by sticking to a simple
framework for writing and running tests.
Some of that may have been lost in a effort to model J-Unit or to
expose all the parts in support of people who want to use subclassing
to write their own unittest variants and extensions (I have seen this
in practice but it is somewhat rare).
If making big changes to the unittest API is on the table, it is worth
considering alternatives like py.test which is more powerful, easier to
learn, much less verbose, and more in line with the way python is
usually written.
gvanrossum commentedon Apr 8, 2008
Agreed that the various loader classes etc. are mostly a waste. The sad
thing is that everyone who is serious about unittests has to reinvent
the code that finds files ending in _test.py on the filesystem, or
something like that, since that's *not* supported directly.
purcell commentedon Apr 8, 2008
Hey, I'm open to anything. If I started writing unittest from scratch
knowing what I know now, I'd probably have kept the API a little
slimmer. Oh, and I'd have named everthing according to Python
conventions; my deepest and belated apologies for that.
I think the design has held up pretty well, even if it's arguably not
the most pythonic. Its familiarity to users of other xUnit frameworks
really does help new Pythoneers start writing tests immediately. And as
for the TestLoader stuff, it looks (and perhaps is) a bit overblown, but
I can't count the number of times people have asked me how to do obscure
or unusual things with the module and I've been able to respond with
something like, "just write a custom TestLoader/TestRunner".
I don't intend to take unittest in any particular direction; truth be
told, I'm now only an occasional visitor to the land of Python, and I
don't think I've had commit rights since the move to subversion. My
continued involvement with the unittest tickets is mainly to help
provide input along the lines of "we discussed this years ago, and
decided against it / thought it would be great". Far be it from me to
stand in the way of progress -- I'd be happy to see unittest re-worked
in any way that makes sense.
gvanrossum commentedon Apr 9, 2008
I think the current consensus is to start trimming the API in 3.1. We
could start documenting best practices in 2.6 and 3.0 though.
Though I wonder how common that use case is. Not all new Pythoneers
come from Java, you know... Many come from Perl, PHP, even C++, and
more and more come from not programming at all before.
I hope we can add more custom TestLoader/TestRunner subclasses for
some of the *common* use cases.
And thanks for your continued involvement! I think the clue the
developer community can take from this is not to worry too much about
changing the original design; you don't seem to have a strong sense of
"ownership", which (in this case) sounds good to me.
purcell commentedon Apr 9, 2008
Hey, I came to Python from Perl, Java *and* C++! I'm pretty sure the
xUnits in all those other languages hold to the same basic API.
Adding more TestLoaders/TestRunners sounds like an excellent move. I'd
expect that once those common conveniences have been provided for, the
core TestSuite/TestCase scheme will continue to be helpful.
I could certainly envisage the provision of convenience decorators that
would remove some of the typical subclassing boilerplate by
transforming plain functions into TestCases.
I was recently sent a fun paper describing a mechanism for transforming
doctests into 'unittest' tests, so there's obviously a lot of scope for
fun additions and changes.
I'll be interested to see what people come up with, and to help a little
if and when I can.
pupeno commentedon Aug 10, 2008
Is there anything that can be done now about this issue? like renaming
the API and leaving the old names as aliases? If so, let me know and
I'll try to work on it.
gpshead commentedon Jan 29, 2009
FYI - As a side note to this issue of removing the clutter of alternate
names - I intend to gather up the worthy non-clutter additional unittest
assertFoo APIs that we have at Google to contribute towards 3.1/2.7, my
goal is to do this before PyCon this year.
This thread from last spring summarizes the types of things I'd like
include already.
http://mail.python.org/pipermail/python-dev/2008-April/078716.html
46 remaining items
gpshead commentedon Apr 3, 2009
assertMultiLineEqual might be reasonable as a default assertEqual for
unicode. I wouldn't want to do it for bytes (py 2.x string).
voidspace commentedon Apr 3, 2009
Fair point. :-)
voidspace commentedon Apr 4, 2009
I'd like to add assertIs and assertNotIs.
We have these at work and I would find them useful whilst writing tests
for another set of changes to unittest I'm currently working on!
pitrou commentedon Apr 4, 2009
Le samedi 04 avril 2009 à 15:06 +0000, Michael Foord a écrit :
Let's call it AssertIsNot (we type "x is not None", not "x not is
None").
voidspace commentedon Apr 4, 2009
I would *mmuch* prefer assertIsNot but it is not symmetrical with the
other asserts.
pitrou commentedon Apr 4, 2009
Well, apparently assertIsNotNone() has been added, so it would be good
to be symmetrical with that :)
benjaminp commentedon Apr 4, 2009
I found while merging this to Py3k that dicts can't be used in
assertSameElements because they are unorderable in py3k.
voidspace commentedon Apr 4, 2009
Patch with assertIs and assertIsNot. Docs but nothing in NEWS as already
covered.
Ok to apply?
voidspace commentedon Apr 4, 2009
Patch for Py3k with fallback for comparing unsortable sequences in
assertSameElements.
Removed the expected failure and added another test case to confirm that
this patch works for unsortable sequences that are the same (no fail)
and different (fail).
pitrou commentedon Apr 4, 2009
Seeing how a change in assertNotEqual unveiled a bug in OrderedDict,
would it be desireable for each of assertEqual and assertNotEqual to
test both the '!=' and '==' operators?
ncoghlan commentedon Apr 4, 2009
No, because the rich comparison docs explicitly state that the
interpreter makes no assumptions about the relationship between != and
== (or, more precisely, __eq__ and __ne__).
"""There are no implied relationships among the comparison operators.
The truth of x==y does not imply that x!=y is false. """
(from http://docs.python.org/reference/datamodel.html#basic-customization)
If someone is writing unit tests for comparison methods they should
explicitly test all 6 operations.
gpshead commentedon Apr 5, 2009
fyi - Your docs in unittest-assertis.diff mention the wrong method name
(assertIsNotNone instead of assertIsNot). fix that and commit.
The unittest-sameelements.diff patch looks good.
voidspace commentedon Apr 5, 2009
Committed in revision 71263. Closing as there is nothing outstanding on
this issue.