On Sun, Dec 26, 2010 at 9:55 PM, Will Hardy wrote:
> It's true that there isn't any rich API for the Error/Fail distinction. The
> best I can think of would be to create a custom exception eg
> FailedAssumption, which is raised when the TestCase.failedException (same as
> AssertionError) is caugh
It's true that there isn't any rich API for the Error/Fail distinction. The
best I can think of would be to create a custom exception eg
FailedAssumption, which is raised when the TestCase.failedException (same as
AssertionError) is caught while testing an assumption.
Here are four ways I can thin
On 25/12/2010, at 3:33 AM, Alex Gaynor wrote:
>
>
> On Fri, Dec 24, 2010 at 12:56 PM, Will Hardy wrote:
> Maybe we could add a keyword argument to Django's TestCase.assert*() methods
> that raises an AssertionError instead of failing the test when the method's
> condition is not met (I assu
On Fri, Dec 24, 2010 at 12:56 PM, Will Hardy wrote:
> Maybe we could add a keyword argument to Django's TestCase.assert*()
> methods that raises an AssertionError instead of failing the test when the
> method's condition is not met (I assume that the test should error instead
> of failing).
>
> e
Maybe we could add a keyword argument to Django's TestCase.assert*() methods
that raises an AssertionError instead of failing the test when the method's
condition is not met (I assume that the test should error instead of
failing).
eg:
self.assertEqual(1, 1, test_assumption=True)
Cheers,
Will
On Thu, 2010-12-23 at 11:46 -0500, Karen Tracey wrote:
> Well, great, status wasn't 200 but what was it? That's information I'd
> really rather get by default, so I much prefer assertEquals, which
> tells me:
>
> Traceback (most recent call last):
> File [snipped]
> self.assertEqual(res.stat
On 23 December 2010 17:56, Ian Clelland wrote:
> On Thu, Dec 23, 2010 at 8:46 AM, Karen Tracey wrote:
>> On Thu, Dec 23, 2010 at 8:44 AM, Luke Plant wrote:
>> Perhaps it is not a problem when using bare asserts for this purpose, but I
>> have grown to dislike asserts in testcases because they gi
My team has adopted the convention of prepending "Sanity:" to the message of
any assertion whose purpose is to verify that things are set up correctly
for the
'main act' assertions. This helps us cut through the 'something is broken,
but it's
not here' noise when a change causes a bunch of tests t
On Thu, Dec 23, 2010 at 8:46 AM, Karen Tracey wrote:
> On Thu, Dec 23, 2010 at 8:44 AM, Luke Plant wrote:
> Perhaps it is not a problem when using bare asserts for this purpose, but I
> have grown to dislike asserts in testcases because they give so little
> information. For example, I am working
On Thu, Dec 23, 2010 at 8:44 AM, Luke Plant wrote:
> Hi all,
>
> This is a question of test code style.
>
> In tests in my own projects, I use both the Python 'assert' statement
> and the unittest TestCase.assert* methods, with the following
> distinction:
>
> * The 'assert' statement is used to
On Thu, Dec 23, 2010 at 5:44 AM, Luke Plant wrote:
> Hi all,
>
> This is a question of test code style.
>
> In tests in my own projects, I use both the Python 'assert' statement
> and the unittest TestCase.assert* methods, with the following
> distinction:
>
> * The 'assert' statement is used to m
Hi all,
This is a question of test code style.
In tests in my own projects, I use both the Python 'assert' statement
and the unittest TestCase.assert* methods, with the following
distinction:
* The 'assert' statement is used to make assertions about the
assumptions built in to *this* bit of code
12 matches
Mail list logo
