canonical-django team mailing list archive

[James Westby <james.westby@xxxxxxxxxxxxx>]

On Mon, 14 Jun 2010 12:46:05 +0200, Jamu Kakar <jamshed.kakar@xxxxxxxxxxxxx> wrote:
> I don't have specific Django advice, but things we've discovered in
> Landscape that might help you:
> 
> - Create whatever sample data you need in each test.  Use helper
>   methods to create sample objects and avoid boilerplate.  Robert's
>   testresources package is also a very nice way to encapsulate and
>   share common "this test needs a thing" code.

Django has "fixtures" that is like sampledata that is tied to a
particular TestCase class. This would be a better idea than global
sampledata if a test ever needed more data than could usefully be
created in a test (a thousand lines of setup isn't going to make the
test readable.)

> - With PostgreSQL at least, the cost of dropping and recreating
>   tables is higher than deleting all the data in every table, when
>   you have a small amount of data.  We've found that DELETE FROM is
>   faster than TRUNCATE in these cases, too.

Django by default doesn't commit, so I assume that works better until
you have a need to commit in the tests?

> - Use a patching system that can upgrade a database to the patch
>   level expected by the code and make your test suite do this
>   automatically, when it detects a mismatch.  There's some code in
>   canonical.schema in the Landscape code base [1] that we really
>   ought to move out to a lazr package, but until then you might find
>   it useful.  This auto-updating helps to keep branch switching a
>   fairly painless process.  You just run 'make check' in the new
>   branch without needing to worry about database state.

Sounds like a good idea.

I have a related issue of managing things like settings.py in multiple
branches.

> For that matter, the behaviour of views will also benefit from being
> covered by unit tests.

Agreed. The increased difficultly of testing views means that where
possible the code, and hence the tests, should go elsewhere. Any code
that is in a view should be tested though, preferably with unit tests.

> Sounds cool!  The most brittle things we've found are assertions
> about strings in HTML content.  Things like:
> 
>     self.assertIn("Logout", browser.contents)
> 
> tend to be flaky.

Agreed. I'll make sure that use case is covered in my library.

> Take a peek at src/canonical/landscape/javascript to see our code
> and related tests.  I suggest you talk to Sidnei about the test
> suite integration details, he knows more about it than I do.

Thanks, I will look at this when we get to javascript.

Thanks,

James