Oops, I accidentally hit Reply instead of Reply to All...
On Wed, Sep 28, 2011 at 1:05 PM, Michael Foord wrote:
> 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
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
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 pa
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 throw
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
On Sep 27, 2011 5:56 PM, 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 years) that it doesn't mer
On 27 Sep, 11:58 pm, ckay...@zindagigames.com wrote:
On Tue, Sep 27, 2011 at 4:43 PM, Steven D'Aprano
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 th
On Tue, Sep 27, 2011 at 4:43 PM, Steven D'Aprano 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:
>
> "IOError is allowed,
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 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
condition
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 k
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
http://mail.python.org/mailman/listinfo/python
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
13 matches
Mail list logo
