2009-12-30 6 views
8

Ich habe ein ziemlich komplexes Django-Projekt, das es schwierig macht, Fixtures zum Laden von Daten zu verwenden.Laden von SQL-Dump vor dem Ausführen von Django-Tests

Was ich tun möchte, ist ein Datenbank-Dump vom Produktions-Datenbank-Server zu laden, nachdem alle Tabellen vom Tester erstellt wurden und bevor die eigentlichen Tests gestartet werden.

Ich habe verschiedene "Magie" in MyTestCase.setUp() versucht, aber ohne Glück.

Alle Vorschläge wären sehr willkommen. Vielen Dank.

+2

Wenn ich mich nicht irre Laden SQL würde schneller sein, weil es nicht den Overhead hat, die Leuchten zu tun. Ich suche das gleiche Problem zu lösen. Ich muss eine große Datenbank zum Testen laden, und ich möchte das Laden schnell halten. – Jeff

+0

Ich verwende generische Beziehungen ausgiebig, was ein Problem bei der Verwendung von Fixtures ist. Es scheint, dass dies gerade in der Arbeit zu 1.2 gelöst wurde, siehe http://docs.djangoproject.com/en/dev/topics/serialization/#natural-keys – knutin

+4

Es ist eine Schande, dass man Kommentare nur nach oben und nicht nach unten abstimmen kann. Dieser erste Kommentar stinkt nur. – boatcoder

Antwort

0

Möglicherweise müssen Sie einen benutzerdefinierten Test-Runner definieren. Es gibt ein paar Informationen hier:

Grundsätzlich denke ich, Sie können einfach kopieren Sie die Standard-Test-Runner von django.test.simple.run_tests und dann ändern Sie es an Ihre Bedürfnisse anzupassen.

Ich habe das vorher nicht getan, aber von meinem Verständnis her wäre das die Möglichkeit, dies anzupassen.

-1

Leuchten sind die beste Option. Haben Sie versucht, mit ./manage.py dumpdata ein Fixture aus Ihrer aktuellen Datenbank zu erstellen? Ich habe nicht gesehen, dass das bei komplexen Modellen fehlschlägt, aber ich denke, es ist möglich.

Angenommen, Sie verwenden mysql, sollten Sie in der Lage sein, dies zu skripten, indem Sie mysqldump verwenden.

7

Django unterstützt das Laden von SQL-Dateien, wenn syncdb tut, Reset oder einen Testläufer starten - das ist genau das, was Sie beschreiben:

http://docs.djangoproject.com/en/dev/howto/initial-data/#providing-initial-sql-data

Sie benötigen ein "SQL" Verzeichnis in der App erstellen Verzeichnis und dann eine Datei namens "mymodel.sql" in diesem Verzeichnis (wobei "MyModel" der entsprechende Modellname ist).

Sie können diese SQL mit Dump-Tools für Ihre Datenbank erstellen.

  • SQLite [1]: echo '.dump' | sqlite3 yourdbname.sqlite> MeineAnw/SQL/mymodel.sql
  • MySQL [2]: Mysqldump yourdbname> MeineAnw/SQL/mymodel.sql
  • PostgreSQL [3]: pg_dump yourdbname> MeineAnw/SQL/mymodel.sql

Nach dem Dumping müssen Sie die Datei bearbeiten, um alles außer den entsprechenden INSERT-Anweisungen oder anderen komplizierten Dingen zu entfernen. Insbesondere müssen Sie Transaktionsverarbeitung, Indexerstellung und Tabellenerstellung von SQL entfernen, um Fehler beim Laden doppelter Erstellungsanweisungen zu vermeiden.

Ich benutze diese Methode für das Laden wirklich, wirklich große Geräte - es dauert viel zu lange, um die JSON zu verarbeiten, aber ein geradliniger SQL-Import ist ziemlich bissig.

Beachten Sie, dass diese Methode das sql für jeden Aufruf von synchdb, reset usw. lädt, zusätzlich zum Laden von Daten für den Test-Runner - so dass Sie keine unterschiedlichen Daten für verschiedene Testfälle haben können , und Sie müssten Dateien vor einem Zurücksetzen entfernen, wenn Sie nicht möchten, dass sie wieder auf Ihren Produktionsserver geladen werden.

[1] http://www.sqlite.org/sqlite.html

[2] http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html

[3] http://www.postgresql.org/docs/8.1/static/backup.html#BACKUP-DUMP

+11

Seit diese Antwort veröffentlicht wurde, ist dieses Verhalten in Django nicht mehr verfügbar. Django 1.2 ignoriert nun 'sql' Dateien im' sql/'Verzeichnis, wenn das Testframework ausgeführt wird. –