Test unità Django senza creare database di test ogni volta che corro

Question

Sembra che "manage.py test" crei database di test ogni volta che eseguo il test. C'è un modo per evitare di creare database di test ogni volta che eseguo il test, ma semplicemente troncare i dati (flush)?

Le mie tabelle sono quasi 40 tavoli (anche per singola app, non l'intero progetto) e mi fanno star male ogni volta che eseguo il test.

Answer 1

A seconda delle esigenze si hanno poche scelte:

• si potrebbe scrivere un corridore test personalizzato o regolare di default: https://docs.djangoproject.com/en/1.6/topics/testing/advanced/#other-testing-frameworks

• si potrebbe usare SimpleTestCase

• Ci sono anche add-on come django-test-utils (anche se non sono sicuro se quello specifico funziona con le moderne versioni di Django).

• In alternativa, per accelerare tutto, è possibile utilizzare SQLite's in-memory database O creare il test database in RAM disk (like tmpfs or ramfs) - in realtà questo è ortogonale all'utilizzo di altre tecniche.

Answer 2

django-naso supporta il riutilizzo del database:

https://github.com/django-nose/django-nose#enabling-database-reuse

però, assicuratevi di leggere i commenti:

Quella nuova ruga è che, ogni volta che lo schema di DB modifiche, si dovrebbe lasciare la bandiera la prossima volta che si esegue test. Questo suggerirà il test runner per reinizializzare il database di test.

Inoltre, REUSE_DB non è compatibile con TransactionTestCases che lasciano spazzatura nel DB, in modo da essere sicuri di fare le vostre TransactionTestCases igienico (vedi sotto) se si desidera utilizzarlo.

Answer 3

La seguente soluzione ridurrà anche il tempo di creazione del db se vi è più numero di migrazioni del sud. Durante i test unitari, eseguire syncdb invece di eseguire tutte le migrazioni del sud sarà molto più veloce.

SOUTH_TESTS_MIGRATE = False # Per disabilitare le migrazioni e utilizzare syncdb invece

Answer 4

Sto indovinando questo non è delle migliori pratiche, ma qualcosa che ho fatto come una soluzione è quella di creare un test alcuni differenti programmi nella directory di gestione/comandi all'interno dell'app.

https://docs.djangoproject.com/en/1.7/howto/custom-management-commands/

Per esempio, sto lavorando su un app, ora che richiede alcune funzionalità avanzate Postgres (non può usare SQLite) in modo, invece di creare funzioni di test come parte di tests.py, ho creato test_process.py in myapp/management/commands/

Answer 5

Da Django 1.8 su si potrebbe usare il flag --keepdb, quando si chiama il gestore.py

Nuovo in Django 1.8: È possibile evitare che i database di test di essere distrutto con l'aggiunta del --keepdb bandieraal comando di prova. Questo sarà preservare il database di test tra le esecuzioni. Se il database non esiste , verrà prima creato. Eventuali migrazioni verranno applicate anche per tenerlo aggiornato. (https://docs.djangoproject.com/en/1.8/topics/testing/overview/#the-test-database)

Quindi la chiamata potrebbe apparire come segue:

python manage.py test --keepdb 

o utilizzando la scorciatoia -k potrebbe sembrare che:

python manage.py test -k 

Answer 6

si consiglia di avere pytest come corridore di prova. Segue l'esempio di configurazione.

Esempio pytest.ini di file:

[pytest] 
norecursedirs= 
    *.egg 
    .git 
    .tox 
    .env 
    _sass 
    build 
    dist 
    migrations 
    fabfile 
    .tox 
python_files = 
    test_*.py 
    tests.py 
DJANGO_SETTINGS_MODULE=settings.dev 
addopts= 
    --reuse-db 
    --nomigrations 
    --cov=your_app 
    --ignore=.tox 
    --ignore=fabfile 
    --ignore=scripts 
    --ignore=settings 
    --ignore=tmp 
    --cov-report=html 
    --cov-report=term 
    --cov-report=annotate 

Esempio runtests.py di file:

#!/usr/bin/env python 
import os 
import sys 

import pytest 


def main(): 
    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "settings.dev") 
    return pytest.main() 


if __name__ == '__main__': 
    sys.exit(main()) 

Esempio requirements.txt di file:

pytest==3.0.2 
pytest-django==2.9.1 
pytest-cov==2.2.1 

Eseguire i test:

./runtests.py 

Nota: questo effetto viene ottenuto tramite le direttive reuse-db e nomigrations.