One of the main questions is to work out what is slow. You can often gain a
lot by using the new --keep-db option which maintains the test database
between runs meaning you don't have the DDL time each run.

A brute force approach which can have an impact is to install postgres on a
RAM disk, this does have some significant performance implications.

If you are running linux or a brew-installed postgres, it's also possible
that your postgres instance is configured poorly for local development.
Christophe Pettus gave a talk a while back (slides[1]) which gives an
overview of some of the common flags you may want to change from their
1990s defaults. In particular the section on memory may be appropriate.

The ideal way to avoid this though is simply to not use the database as
much as possible. There are various ways to approach this, from mocking it
out, to unit testing various objects, to building ORM objects without ever
calling .save() on them. There are a number of resources online for this.

Personally, I tend not to worry too much about my overall test suite's
speed, so long as I can run the tests for the section I'm working on well I
then rely on the CI to deliver my final answers. As a side note, your CI
should always be trying to mimic live as much as possible - even if you
were to use SQLite locally for testing Django cannot guarantee all
behaviour is completely db agnostic, especially when it comes to constraint
checking.

Marc

[1] http://thebuild.com/presentations/not-your-job.pdf

On 4 May 2015 at 18:00, David Muller <[email protected]> wrote:

> Hi everybody,
>
> Recently I've begun to use the PostgreSQL specific fields introduced in
> Django 1.8.  My codebase actually uses the special fields (HStoreField and
> ArrayField mostly) frequently enough such that I cannot run my test suite
> on an in memory SQLite database -- I have to run on a PostgreSQL instance.
>
> Running my tests on PostgreSQL is fine, but I miss the zippy performance
> of an in memory SQLite database.  If, say, my test code *cannot *be
> refactored itself, what would be your suggested route for test speed
> improvement?  I see this outstanding django ticket for UNLOGGED postgres
> tables <https://code.djangoproject.com/ticket/24306>, and also some work
> by aaugustin towards adding a `--parallel` option to the django tests
> <https://github.com/django/django/pull/4063>.  Another thought I had
> would be creating "dumb" versions of the PostgreSQL fields that worked in
> SQLite.
>
> I realize, of course, that by using `django.contrib.postgres`, I should
> expect to sacrifice Django's "plug and play database backends" -- still
> curious as to your thoughts of improving test speed for projects that use
> postgres specific fields.
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/32aa98c9-a05f-456f-bd0e-96d324104448%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/32aa98c9-a05f-456f-bd0e-96d324104448%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1EXzPaoTS%2BSwTc4chQS-g-KA%2BG2S6WJnnbmhKhN4zSxtw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to