Django Migrations vs Unit Tests

A partir da versão 1.7, o Django conta com um sistema de migrations próprio. Com elas é possível controlar as versões do seu banco de dados, podendo voltar para qualquer versão do Schema que for necessário.

Um sistema como estes significa, também, mais trabalho para o Django fazer. Em um ambiente de produção, não há diferenças perceptíveis — As migrations foram feitas para serem executadas em momentos pontuais — Porém, dependendo da sua configuração, é necessário criar o banco de dados no início da execução e destruir ao final dos testes unitários. Se este é o seu caso, é bem possível que você esteja vendo seus testes ficarem mais lentos à medida que novas migrations são criadas.

Desativando as migrations

Ao que parece, este problema é bem comum. Tanto que há algumas soluções.  Sendo que a mais simples consiste em adicionar o seguinte ao seu arquivo settings.py:

class DisableMigrations(object):
    def __contains__(self, item):
        return True

    def __getitem__(self, item):
        return "notmigrations"

MIGRATION_MODULES = DisableMigrations()

Pode até ficar mais simples que isso, pois esta solução já foi integrada como plugin tanto para o manage.py test quanto para o py.test.

Se você migrou recentemente para o Django 1.7, é bem provável que isto acelere seu desenvolvimento. Os meus testes unitários que demoravam em média 120 segundos, parassaram a demorar apenas 10!

Anúncios

Um pensamento sobre “Django Migrations vs Unit Tests

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s