test cannot find assertContains
Kenneth Gonsalves
I am trying to run a test using assertContains, but get this error:
AttributeError: 'SourceTestCase' object has no attribute
'assertContains'
my code:
from django.utils import unittest
from incident.models import Source
from django.test.client import Client
class SourceTestCase(unittest.TestCase):
fixtures = ['source.json']
def setUp(self):
self.client = Client()
def testSource(self):
response = self.client.get('/incident/sources/')
self.assertEqual(response.status_code, 200)
self.assertContains(response,'phone')
--
regards
KG
http://lawgon.livejournal.com
Coimbatore LUG rox
http://ilugcbe.techstud.org/
Mike Ramirez
On Friday, March 11, 2011 10:19:27 pm Kenneth Gonsalves wrote:
> hi,
>
> I am trying to run a test using assertContains, but get this error:
>
> AttributeError: 'SourceTestCase' object has no attribute
> 'assertContains'
>
> my code:
>
> from django.utils import unittest
from django.test import TestCase
the stuff in utils.unittest is unittest2 stuff if you're using python <2.7 (unittest2 is part of 2.7 now as unittest).
assertContains is a django specific test and located in test.TestCase with the others (you can find TransactionTestCase in there also).
Mike
--
The British are coming! The British are coming!
Mike Ramirez
On Friday, March 11, 2011 11:04:39 pm Mike Ramirez wrote:
> assertContains is a django specific test and located in test.TestCase with
> the others (you can find TransactionTestCase in there also).
>
I should also add, TransactionTestCase is the base for TestCase and TestCase is really a patch to convince TransactionTestCase that a transaction occured, but the transaction does nothing.
TestCase's docstring:
"Does basically the same as TransactionTestCase, but surrounds every test with a transaction, monkey-patches the real transaction management routines to do nothing, and rollsback the test transaction at the end of the test. You have to use TransactionTestCase, if you need transaction management inside a test."
Mike
--
Work without a vision is slavery, Vision without work is a pipe dream,
But vision with work is the hope of the world.
Kenneth Gonsalves
> >
> > from django.utils import unittest
>
> from django.test import TestCase
>
> the stuff in utils.unittest is unittest2 stuff if you're using python
> <2.7
> (unittest2 is part of 2.7 now as unittest).
I am using 2.6, but according to the django docs, django has a bundled
version of unittest2 which is accessed from django.utils.unittest which
is meant for python <2.7.
Mike Ramirez
On Friday, March 11, 2011 11:11:21 pm Kenneth Gonsalves wrote:
> On Fri, 2011-03-11 at 23:04 -0800, Mike Ramirez wrote:
> > > from django.utils import unittest
> >
> > from django.test import TestCase
> >
> > the stuff in utils.unittest is unittest2 stuff if you're using python
> > <2.7
> > (unittest2 is part of 2.7 now as unittest).
>
> I am using 2.6, but according to the django docs, django has a bundled
> version of unittest2 which is accessed from django.utils.unittest which
> is meant for python <2.7.
The problem here is that assertContains is not part of unittest/unittest2.
It's defined in TransactionTestCase in django.test, which extends unittest2.TestCase and adds in assertContains, assertNotContains, assetFormError, basically django specific assertions.
Mike
--
<rm_-rf_> The real value of KDE is that they inspired and push the
development of GNOME :-)
-- #Debian
Mike Ramirez
On Friday, March 11, 2011 11:21:02 pm you wrote:
> The problem here is that assertContains is not part of unittest/unittest2.
>
> It's defined in TransactionTestCase in django.test, which extends
> unittest2.TestCase and adds in assertContains, assertNotContains,
> assetFormError, basically django specific assertions.
>
>
> Mike
Sorry faster trigger finger tonight. But I want to add, I think we're meant to use the stuff in django.test for our tests.
Mike
--
The worst sin towards our fellow creatures is not to hate them,
but to be indifferent to them; that's the essence of inhumanity.
-- G.B. Shaw
Kenneth Gonsalves
> On Friday, March 11, 2011 11:21:02 pm you wrote:
> > The problem here is that assertContains is not part of
> unittest/unittest2.
> >
> > It's defined in TransactionTestCase in django.test, which extends
> > unittest2.TestCase and adds in assertContains, assertNotContains,
> > assetFormError, basically django specific assertions.
> >
> >
> > Mike
>
> Sorry faster trigger finger tonight. But I want to add, I think we're
> meant
> to use the stuff in django.test for our tests.
*now* I understand. I replaced
from django.utils import unittest
with
from django.test import TestCase
and all is well. I think the dev docs need to be clearer on this point
and mention this at the outset. After all they *are* dev docs.
Mike Ramirez
On Friday, March 11, 2011 11:37:38 pm Kenneth Gonsalves wrote:
> and all is well. I think the dev docs need to be clearer on this point
> and mention this at the outset. After all they *are* dev docs.
http://docs.djangoproject.com/en/1.2/topics/testing/#testcase
Mike
--
Would that my hand were as swift as my tongue.
-- Alfieri
werefr0g
As far I can tell from the documentation, to use Django's extended TestCase, you should use django.test.TestCase [1]. Using django.utils.unittest allows you to benefit from python 2.7 unittest2 library, [2]
Regards,
[1] http://docs.djangoproject.com/en/dev/topics/testing/#django.test.TestCase
[2] http://docs.djangoproject.com/en/dev/topics/testing/#writing-unit-tests
Kenneth Gonsalves
> On Friday, March 11, 2011 11:37:38 pm Kenneth Gonsalves wrote:
>
> > and all is well. I think the dev docs need to be clearer on this
> point
> > and mention this at the outset. After all they *are* dev docs.
>
> http://docs.djangoproject.com/en/1.2/topics/testing/#testcase
I know it is there - but it is half way down the page. My point is that
it should be at the top of the page. For what it's worth I filed a
ticket.
Mike Ramirez
On Sunday, March 13, 2011 09:58:18 pm Kenneth Gonsalves wrote:
> On Sat, 2011-03-12 at 00:12 -0800, Mike Ramirez wrote:
> > On Friday, March 11, 2011 11:37:38 pm Kenneth Gonsalves wrote:
> > > and all is well. I think the dev docs need to be clearer on this
> >
> > point
> >
> > > and mention this at the outset. After all they *are* dev docs.
> >
> > http://docs.djangoproject.com/en/1.2/topics/testing/#testcase
>
> I know it is there - but it is half way down the page. My point is that
> it should be at the top of the page. For what it's worth I filed a
> ticket.
I've een wondering about this myself, but I'm not sure that it's in the wrong place, but it's not in the perfect place.
IMO, it's in its natural place if you apply how the other docs are split up. Testing is a single page and doesn't benefit from the seperation say something like forms gets. This is where the problem probably lies.
If you look at the forms api, it describes the basic forms api with just forms.Form, and goes into how to use the forms, later on you run into forms.ModelForm in it's own page. All of this depends on prior knowledge and steps down in a logical pattern i.e. forms, fields, widgets.
Testing works the same way, introducing the basic unit testing functionality, including how to build simple tests. Then works through running them. I think it's natural to stop reading there, but we are intended to continue on down through the whole page as it builds on itself, like the rest of the docs.
Also starting with unittest shows that we can use unittest as we need (in a non django lib, for example a img lib for handling all the image resizes/changes we may want. this wouldn't require any django related tests. There is no questioning the if testrunner will question these. Also ending with testing.TestCase leaves that fresher in our minds as it's the last thing we read (theoretically).
ftr, in atleast 1.2.3 forward startapp generates a tests.py with this code:
[gmike@priss keis]$ cat newfun/tests.py
"""
This file demonstrates writing tests using the unittest module. These will pass
when you run "manage.py test".
Replace this with more appropriate tests for your application.
"""
from django.test import TestCase
class SimpleTest(TestCase):
def test_basic_addition(self):
"""
Tests that 1 + 1 always equals 2.
"""
self.assertEqual(1 + 1, 2)
*note: 1.2.3 also has docstring tests included as part of the sample/exmaple.
With this all in mind, I think they do enough to say use 'django.testing', without having it specifically marked at the start.
But it could possibly benefit from being two pages, one an "overview" and one page for "django.testing"
Mike
--
solar flares
Kenneth Gonsalves
> > I know it is there - but it is half way down the page. My point is
> that
> > it should be at the top of the page. For what it's worth I filed a
> > ticket.
>
> I've een wondering about this myself, but I'm not sure that it's in
> the wrong
> place, but it's not in the perfect place.
all I am doing is giving the devs feedback from a dumb user ;-) The docs
have evolved historically, but now and then maybe a restructuring has to
be done - and some times the restructuring doesn't help. For example the
internationalisation docs have now been split into i18n and l10n
sections. This causes some confusion as most people are not clear about
the difference between these two.
Mike Ramirez
On Sunday, March 13, 2011 10:40:51 pm you wrote:
> With this all in mind, I think they do enough to say use 'django.testing',
> without having it specifically marked at the start.
>
> But it could possibly benefit from being two pages, one an "overview" and
> one page for "django.testing"
>
>
> Mike
err... s/django.testing/django.test/g
Mike
--
"The trouble with doing something right the first time is that nobody
appreciates how difficult it was."
-- Walt West
Mike Ramirez
On Sunday, March 13, 2011 10:58:10 pm Kenneth Gonsalves wrote:
> On Sun, 2011-03-13 at 22:40 -0700, Mike Ramirez wrote:
> > > I know it is there - but it is half way down the page. My point is
> >
> > that
> >
> > > it should be at the top of the page. For what it's worth I filed a
> > > ticket.
> >
> > I've een wondering about this myself, but I'm not sure that it's in
> > the wrong
> > place, but it's not in the perfect place.
>
> all I am doing is giving the devs feedback from a dumb user ;-) The docs
> have evolved historically, but now and then maybe a restructuring has to
> be done - and some times the restructuring doesn't help. For example the
> internationalisation docs have now been split into i18n and l10n
> sections. This causes some confusion as most people are not clear about
> the difference between these two.
As I was writing that I was wondering if I should have done that in your bug report. I just linked my message to it.
Mike
--
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things.
-- Doug Gwyn