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 to fail. This works
equally
well with 2-arg assert or assertEquals() et al.
Dave
On Thu, Dec 23, 2010 at 8:56 AM, Ian Clelland <clell...@gmail.com> wrote:
> On Thu, Dec 23, 2010 at 8:46 AM, Karen Tracey <kmtra...@gmail.com> wrote:
> > On Thu, Dec 23, 2010 at 8:44 AM, Luke Plant <l.plant...@cantab.net>
> 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 with test code that uses bare
> asserts
> > all over the place instead of the TestCase methods and when these tests
> fail
> > I get errors like this:
> >
> > Traceback (most recent call last):
> > File [snipped]
> > assert res.status_code == 200
> > AssertionError
> >
> > 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.status_code, 202)
> > AssertionError: 302 != 200
> >
> > That actually gives me enough information that I might be able to fix the
> > problem straight off.
> >
> > Do you not find the paucity of information provided by bare assert to be
> > annoying?
>
> Test cases should probably be using the two-argument form of assert:
>
> assert (res.status_code == 200), "The status code returned was
> incorrect"
>
> or even
>
> assert (res.status_code == 200), ("%s != 200" % res.status_code)
>
> At least some of the examples that Luke pointed to are using that
> style, and it definitely makes more sense than just asserting a bare
> fact, with no explanation.
>
>
> Regards,
> Ian Clelland
> <clell...@gmail.com>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
