Gregory P. Smith g...@krypto.org added the comment:
New patch uploaded. Based on mfoord's 200903301411 version. Adds
documentation. Cleans up a few things and fixes names on a few things.
This patch has been put up for review in:
http://codereview.appspot.com/32080
--
Added file:
Gregory P. Smith g...@krypto.org added the comment:
fixed the unintentional extra edits in the docs in gps04.
--
Added file: http://bugs.python.org/file13510/unittest-new-asserts-gps04.diff.txt
___
Python tracker rep...@bugs.python.org
Changes by Gregory P. Smith g...@krypto.org:
Removed file:
http://bugs.python.org/file13480/unittest-new-asserts-gps02.diff.txt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2578
___
Changes by Gregory P. Smith g...@krypto.org:
Removed file: http://bugs.python.org/file13484/unittest-new-asserts.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2578
___
Changes by Gregory P. Smith g...@krypto.org:
Removed file:
http://bugs.python.org/file13509/unittest-new-asserts-gps03.diff.txt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2578
___
Gregory P. Smith g...@krypto.org added the comment:
Updated patch after sprinting on this with Michael Foord.
TODO:
* update assertRaisesWithRegexpMatch to be a context manager.
* documentation.
i'm working on the docs now.
--
Added file:
Changes by Gregory P. Smith g...@krypto.org:
Removed file:
http://bugs.python.org/file13447/unittest-new-asserts-gps01.diff.txt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2578
___
Antoine Pitrou pit...@free.fr added the comment:
Updated patch after sprinting on this with Michael Foord.
TODO:
* update assertRaisesWithRegexpMatch to be a context manager.
Wouldn't it be simpler to make assertRaises return the exception and let
the calling code match it as it feels
Guido van Rossum gu...@python.org added the comment:
Antoine Pitrou pit...@free.fr added the comment:
Wouldn't it be simpler to make assertRaises return the exception and let
the calling code match it as it feels like?
Hm, that sounds awfully familiar. I can't recall if there was ever a
good
Antoine Pitrou pit...@free.fr added the comment:
Wouldn't it be simpler to make assertRaises return the exception and let
the calling code match it as it feels like?
Hm, that sounds awfully familiar. I can't recall if there was ever a
good reason not to do this.
IIRC some people felt
Michael Foord mich...@voidspace.org.uk added the comment:
New patch with assertRaisesWithRegexMatch as a context manager.
--
keywords: +patch
nosy: +mfoord
Added file: http://bugs.python.org/file13484/unittest-new-asserts.diff
___
Python tracker
Michael Foord mich...@voidspace.org.uk added the comment:
Updated patch with asserts in unittest changed to explicitly raising
self.failureException, hardcoded AssertionError in tests changed to
self.failureException and addition of assertRegexMatches.
--
Added file:
Antoine Pitrou pit...@free.fr added the comment:
I -did- add casing for the type to the main assertEqual method so it may
make sense to make the new type specific methods private so that they're
not part of the public API (ie: I agree with pitrou that it seems
pointless).
Well, that's my
Guido van Rossum gu...@python.org added the comment:
The naming pattern (assertListEqual, assertDictEqual, etc.) is pretty
easy to pick up so I don't think the addition of several new methods is
a big deal. Making assertEqual() do the right thing all the time is
hard if there are subclasses
Changes by Skip Montanaro s...@pobox.com:
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2578
___
___
Python-bugs-list mailing list
Unsubscribe:
Skip Montanaro s...@pobox.com added the comment:
Personally, I would prefer it if unittest got rid of all the various
ways to spell assert and just let test cases use the assert statement.
I use nose for most of my stuff which supports/allows use of the assert
statement. I think my test cases
Skip Montanaro s...@pobox.com added the comment:
Just in case it can't be retrieved, here is Greg's text from msg84360:
Oh for reference, i left these out but they may interest people for
completeness sake.
assert_ 15%
assertTrue 9%
assertFalse 5%
We
Guido van Rossum gu...@python.org added the comment:
I would love to use the time machine to kill the 'fail' variants as well
as 'assert_'. However they are in use and we don't want to break
people's tests. Breaking tests is painful. And there are a lots of
tests. So we'll have to support
Benjamin Peterson benja...@python.org added the comment:
2009/3/29 Guido van Rossum rep...@bugs.python.org:
Guido van Rossum gu...@python.org added the comment:
I would love to use the time machine to kill the 'fail' variants as well
as 'assert_'. However they are in use and we don't want
Gregory P. Smith g...@krypto.org added the comment:
Attaching a patch that adds Google's unittest.TestCase assertFooEqual()
extensions and automatically uses rich comparisons in assertEqual() with
nicely formatted failure messages for list, tuple, dict, set, frozenset.
The following are added
Antoine Pitrou pit...@free.fr added the comment:
With all due respect, I find the presence of numerous type specific
functions (assertListEqual, etc.) awful. I don't understand why the type
isn't simply cased in the standard assertEqual function. I also don't
think adding so many assert methods
Gregory P. Smith g...@krypto.org added the comment:
Some statistics from our large code base as to which of the assert
methods get used relative to the others:
These percentages are relative to the count of assertEqual(s) uses being
100% and cover python code written by a crazy large number of
Gregory P. Smith g...@krypto.org added the comment:
Oh for reference, i left these out but they may interest people for
completeness sake.
assert_ 15%
assertTrue 9%
assertFalse 5%
We don't currently have the auto type checking in assertEqual in our
internal codebase, direct use of the
Changes by Giampaolo Rodola' billiej...@users.sourceforge.net:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2578
___
Guilherme Polo ggp...@gmail.com added the comment:
As an side-side-note, I find much more important to add some kind of
test discovery since it is being duplicated in several packages in Lib/
and will continue being duplicated.
--
nosy: +gpolo
___
Guido van Rossum gu...@python.org added the comment:
@gpsmith: Way to go!
@gpolo: Alas, test discovery is now a much harder problem because it
depends on using conventions for test naming. Unless all existing
implementations use the same conventions, it's hard to see how to
replace them.
Gregory P. Smith g...@krypto.org added the comment:
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
Changes by Gregory P. Smith g...@krypto.org:
--
assignee: purcell - gregory.p.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2578
___
___
Changes by Gregory P. Smith g...@krypto.org:
--
priority: - normal
versions: +Python 2.7, Python 3.1 -Python 3.0
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2578
___
J. Pablo Fernández [EMAIL PROTECTED] added the comment:
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.
--
nosy: +pupeno
___
Python
Guido van Rossum [EMAIL PROTECTED] added the comment:
Steve Purcell [EMAIL PROTECTED] 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
Steve Purcell [EMAIL PROTECTED] added the comment:
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
New submission from Benjamin Peterson [EMAIL PROTECTED]:
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
Guido van Rossum [EMAIL PROTECTED] added the comment:
My plan:
- add deprecations to 3.1
- remove in 3.3
--
nosy: +gvanrossum
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2578
__
Raymond Hettinger [EMAIL PROTECTED] added the comment:
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.
--
assignee: - purcell
nosy: +purcell, rhettinger
Guido van Rossum [EMAIL PROTECTED] added the comment:
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
Raymond Hettinger [EMAIL PROTECTED] added the comment:
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,
Guido van Rossum [EMAIL PROTECTED] added the comment:
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
38 matches
Mail list logo
