canonical-django team mailing list archive

[James Westby <james.westby@xxxxxxxxxxxxx>]

On Mon, 14 Jun 2010 11:51:44 +0200, Jamu Kakar <jamshed.kakar@xxxxxxxxxxxxx> wrote:
> 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.

That's good to know. We're not at the stage of deploying anything yet,
we just had our planning sprint last week, but I made the tests default
to sqlite partly for speed, and partly for ease of setup.

If you have specific tips about quick tests with Django and Postgres
that would be great to share.

> 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.

Agreed.

> 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.

I'm not sure I follow the last sentence.

> 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)

getLink works on the text contained in the <a> tag?

I'm working on a project that might help in writing robust tests for
html, I hope to post to canonical-tech about it soon. Information on
what makes such tests brittle would be good though.

> 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.

I'd love to look at that. Unit tests will help avoid requiring too much
of windmill/selenium-based tests.

Thanks,

James