Antoine Pitrou added the comment:
Also, see issue #19645.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18054
___
___
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18054
___
___
Python-bugs-list
Changes by vila v.ladeuil+bugs-pyt...@free.fr:
--
nosy: +vila
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18054
___
___
Python-bugs-list mailing
Nick Coghlan added the comment:
I think something like assertThat could address the problem nicely. Probably
best to propose it as a separate issue, then we can make this one depend on
that one if we decide to go that way.
--
___
Python tracker
Robert Collins added the comment:
Hey, feel free to +nosy me on unittest things :). Julian pinged me on IRC about
this - Jml and I would be delight to prepare a patchset for assertThat for
unittest and as much of the core of Matchers as makes sense. The bare core can
come in without any of
Nick Coghlan added the comment:
I like the idea of using the strategy pattern to at least decouple the
assertion API from the main testcase API. I also like it better than the mixin
suggested earlier.
We would obviously have to keep the existing methods for backwards
compatibility, but could
Julian Berman added the comment:
I don't either really off the top of my head, though I've toyed with some
things.
If there's support for some exploration I wouldn't mind attempting a POC
externally though.
--
___
Python tracker
Michael Foord added the comment:
There's always (almost) support for exploration...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18054
___
___
Ezio Melotti added the comment:
What about adding a recipes section in the docs with sample implementation of
specific assertMethods?
--
nosy: +ezio.melotti
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18054
Julian Berman added the comment:
Can I throw in, and hopefully not in a way that's too out of place, that I
think that unittest might want to rethink it's strategy re: assertion methods?
The fact that the object that has all the assertions and the object that has
the logic for running a test,
Raymond Hettinger added the comment:
+1 to what Michael said. The current API is way too big, but these proposed
methods aren't trivially easy to get right. It would be nice to have them done
once and done well.
--
nosy: +rhettinger
___
Python
Michael Foord added the comment:
I'm slightly torn.
TestCase has a wide (wy too wide) API and adding methods makes it wider.
The use cases for these methods are relatively niche, so my instinct would be
that these don't meet the bar for inclusion on TestCase.
On the other hand, despite
Serhiy Storchaka added the comment:
I'm sure not all user of the TestCase class even know about all it's existing
methods.
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18054
Nick Coghlan added the comment:
I like the idea of a separate mixin class like TracebackMixin or
TracebackHelper.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18054
___
Changes by Aaron Iles aaron.i...@gmail.com:
--
nosy: +aliles
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18054
___
___
Python-bugs-list mailing
New submission from Nick Coghlan:
When creating the error handling tests for the new ipaddress module, one of the
things I added was an assertCleanError method on the test cases [1].
This is a wrapper around assertRaisesRegex which ensures that either no
exception context is set, or if there
16 matches
Mail list logo
