On Thursday, May 25, 2017 at 5:03:54 PM UTC+2, Shai Berger wrote:
>
> Hi,
>
> I apologize for re-raising a thread that's mostly done and decided, but I
> just
> ran into [1] where it says:
>
> """
> Note
>
> Exception messages are not part of the Python API. Their contents may
> change
> fr
Hi,
I apologize for re-raising a thread that's mostly done and decided, but I just
ran into [1] where it says:
"""
Note
Exception messages are not part of the Python API. Their contents may change
from one version of Python to the next without warning and should not be
relied on by code which
On Sunday, April 9, 2017 at 3:24:42 PM UTC+2, Josh Smeaton wrote:
>
> We throw lots of ValueErrors and TypeErrors rather than creating new
> exception types all over the place. There's definitely an argument to be
> made that different exception types can be created. But I know that I've
> defin
We throw lots of ValueErrors and TypeErrors rather than creating new
exception types all over the place. There's definitely an argument to be
made that different exception types can be created. But I know that I've
definitely run afoul of believing I was testing one error (assertRaises)
when I
Without diving into implementation details, I recon I've been taught the
same as Shai. An exception type should have only one purpose, thus testing
the type /should/ be sufficient imho. That said, if you want to TDD the
message, you're going to code a test for it, is there really another way ?
;)
That said more structured attributes on exceptions can be useful for Django
users, if you know any obvious places they are missing.
On 7 April 2017 at 13:23, Adam Johnson wrote:
> I agree with Tim. He's also probably the most familiar with the cost of
> message changes 😊
>
> On 7 April 2017 at 1
I agree with Tim. He's also probably the most familiar with the cost of
message changes 😊
On 7 April 2017 at 12:56, Tim Graham wrote:
> Hi Shai,
>
> Without testing for a message, there's also a possibility that the
> exception you think you're testing isn't the one the test is actually
> raisin
Hi Tim,
> Without testing for a message, there's also a possibility that the
> exception you think you're testing isn't the one the test is actually
> raising.
If you need to verify the error message for that reason, then the exception is
probably not specific enough. Testing the message, in th
Hi Shai,
Without testing for a message, there's also a possibility that the
exception you think you're testing isn't the one the test is actually
raising. I think the readability advantages of including messages in the
tests outweigh the cost of updating tests when a message changes.
On Friday
Hello all,
A recent PR[1] seeks to replace most of the assertRaises() calls in the test-
suite with assertRaisesMessage(). The argument for it is that it then becomes
easier to find the test for some error handling, by grepping the test for the
message text. Also, in some cases, an existing asse
10 matches
Mail list logo
