canonical-django team mailing list archive

[Jamu Kakar <jamshed.kakar@xxxxxxxxxxxxx>]

Hi,

On Sun, Jun 13, 2010 at 9:01 PM, James Westby
<james.westby@xxxxxxxxxxxxx> wrote:
> Testing Models
> ==============
>
> First we spoke a bit about testing models.
>
> We weren't sure about appropriate tests for the basics of models, such
> as creating an object and checking that it has an attribute that was
> defined via a field. This is hampered as in my testing some things about
> the field, such as limits on the length of a string don't seem to be
> enforced in a test environment (with the sqlite3 backend).

Are you using SQLite for tests with something else for production?

We tried this in Landscape, with SQLite for tests and PostgreSQL for
production, and eventually switched to using PostgreSQL for
everything.  We ran into issues where SQLite didn't behave like
PostgreSQL and we want to use PostgreSQL-specific features.  Our
motivation for using SQLite was to keep our test suite fast, but in
practise we've been able to keep it fast and use PostgreSQL.

If that's what you're doing, maybe it'll work out for you, but in
general I think it's best to test with the same database as you
deploy to.

> As we add more behaviour to models we will be testing that, and it was
> agreed that this was where most of the logic should be pushed too, so
> views are as simple as possible.

Behaviour should go in your model, not in your views.  The behaviour
exposed by your model should be covered by unit tests.  For that
matter, the behaviour of unit tests will also benefit from being
covered by unit tests.

> Testing Views
> =============
>
> Django has facilities for testing that a view rendered using a
> particular template, and the paramaters that were passed to a template,
> and we agreed that it would be worthwhile trying to take advantage of
> that.
>
> We also agreed that writing some integration tests that retrieve a page
> and test some parts of the HTML that is returned would be
> worthwhile. This would only test the simple cases though, and not try to
> exhaustively test edge cases, due to the poor failure modes of this
> test. In addition we will be avoiding string comparisons, as they are
> far too brittle.

In Landscape we use Zope's test browser, the analog to Django's test
client, and it works well for us for the kinds of tests you
describe.  We've found that making assertions about HTML content is
prone to error, but using the browser to get named controls works
well.  For example, we often have assertions about links, like:

    link = browser.getLink("Logout")
    self.assertEqual("http://localhost/logout";, link.url)

These clients breaks down when Javascript enters the picture.  At
that point you need something different, like Windmill or Selenium,
to emulate a human opening a page in the browser, clicking around,
etc.  Also, if you're writing Javascript code you should definitely
have unit tests to cover your code.  Landscape has infrastructure
for running YUI3-based unit tests that you might want to look at if
you're planning on writing Javascript.

Thanks,
J.