On 27 September 2011 19:59, Laurens Van Houtven _...@lvh.cc wrote:
Sure, you just *do* it. The only advantage I see in assertNotRaises is that
when that exception is raised, you should (and would) get a failure, not an
error.
It's a useful distinction. I have found myself writing code of the
On Wed, Sep 28, 2011 at 09:43:13AM +1000, Steven D'Aprano wrote:
Oleg Broytman wrote:
On Tue, Sep 27, 2011 at 07:46:52PM +0100, Wilfred Hughes wrote:
+def assertNotRaises(self, excClass, callableObj=None, *args, **kwargs):
+Fail if an exception of class excClass is thrown by
+
On 27/09/2011 19:46, Wilfred Hughes wrote:
Hi folks
I wasn't sure if this warranted a bug in the tracker, so I thought I'd
raise it here first.
unittest has assertIn, assertNotIn, assertEqual, assertNotEqual and so
on. So, it seems odd to me that there isn't assertNotRaises. Is there
any
On 27/09/2011 19:59, Laurens Van Houtven wrote:
Sure, you just *do* it. The only advantage I see in assertNotRaises is
that when that exception is raised, you should (and would) get a
failure, not an error.
There are some who don't see the distinction between a failure and an
error as a useful
Oops, I accidentally hit Reply instead of Reply to All...
On Wed, Sep 28, 2011 at 1:05 PM, Michael Foord fuzzy...@voidspace.org.ukwrote:
On 27/09/2011 19:59, Laurens Van Houtven wrote:
Sure, you just *do* it. The only advantage I see in assertNotRaises is that
when that exception is raised,
Hi folks
I wasn't sure if this warranted a bug in the tracker, so I thought I'd raise
it here first.
unittest has assertIn, assertNotIn, assertEqual, assertNotEqual and so on.
So, it seems odd to me that there isn't assertNotRaises. Is there any
particular motivation for not putting it in?
I've
Sure, you just *do* it. The only advantage I see in assertNotRaises is that
when that exception is raised, you should (and would) get a failure, not an
error.
___
Python-Dev mailing list
Python-Dev@python.org
On Tue, Sep 27, 2011 at 07:46:52PM +0100, Wilfred Hughes wrote:
+def assertNotRaises(self, excClass, callableObj=None, *args, **kwargs):
+Fail if an exception of class excClass is thrown by
+callableObj when invoked with arguments args and keyword
+arguments kwargs.
On 9/27/2011 2:46 PM, Wilfred Hughes wrote:
Hi folks
I wasn't sure if this warranted a bug in the tracker, so I thought I'd
raise it here first.
unittest has assertIn, assertNotIn, assertEqual, assertNotEqual and so
These all test possible specification conditions and sensible test
Oleg Broytman wrote:
On Tue, Sep 27, 2011 at 07:46:52PM +0100, Wilfred Hughes wrote:
+def assertNotRaises(self, excClass, callableObj=None, *args, **kwargs):
+Fail if an exception of class excClass is thrown by
+callableObj when invoked with arguments args and keyword
+
On Tue, Sep 27, 2011 at 4:43 PM, Steven D'Aprano st...@pearwood.info wrote:
But I can't see this being a useful test. As written, exceptions are still
treated as errors, except for excClass, which is treated as a test failure. I
can't see the use-case for that. assertRaises is useful:
On 27 Sep, 11:58 pm, ckay...@zindagigames.com wrote:
On Tue, Sep 27, 2011 at 4:43 PM, Steven D'Aprano st...@pearwood.info
wrote:
But I can't see this being a useful test. As written, exceptions are
still treated as errors, except for excClass, which is treated as a
test failure. I can't see
On Sep 27, 2011 5:56 PM, exar...@twistedmatrix.com wrote:
assertNotRaises doesn't make anything possible that isn't possible now. It
probably doesn't even make anything easier - but if it does, it's so obscure
(and I've read and written thousands of tests for all kinds of libraries
over the
13 matches
Mail list logo
