additional unittest type equality methods

[benjaminp]

BPO	2578
Nosy	@smontanaro, @rhettinger, @gpshead, @ncoghlan, @pitrou, @giampaolo, @benjaminp, @ezio-melotti, @voidspace
Files	unittest-new-asserts.diff unittest-new-asserts-gps04.diff.txt unittest-assertis.diff unittest-sameelements.diff

^{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']

[benjaminp]

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:

if x == y:
   pass
 else:
   raise AssertionError(...)

rather than

 if x != y:
   raise AssertionError(...)

[gvanrossum]

My plan:

• add deprecations to 3.1
• remove in 3.3

[rhettinger]

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]

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]

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]

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]

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]

Steve Purcell <purcell@users.sourceforge.net> added the comment:
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 current consensus is to start trimming the API in 3.1. We
could start documenting best practices in 2.6 and 3.0 though.

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.

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.

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 hope we can add more custom TestLoader/TestRunner subclasses for
some of the *common* use cases.

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.

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]

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]

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]

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