Accéder au serveur de tests Django à partir du test Django

Question

Je souhaite rédiger un test unitaire qui exécute les requêtes HTTP directement (au lieu d'utiliser django.test.client.Client).

Si vous êtes curieux de savoir pourquoi, c’est parce que je veux tester une API Thrift-over-HTTP que j’expose depuis mon application Django, et que je souhaite utiliser le client Thrift dans le test unitaire.

Le problème est que lors des tests, le serveur n’est pas réellement exécuté. Lorsque vous utilisez django.test.client.Client, il appelle simplement les fonctions d'affichage au lieu de créer une requête HTTP. (Corrigez-moi si je me trompe.)

Quel serait donc le meilleur moyen de forcer le framework de test à démarrer le serveur HTTP?

J'ai essayé d'écrire un script bash qui fait quelque chose comme ceci:

./manage.py testserver --addrport 7000 &
PID=$!
sleep 5
./manage.py test --no-input
kill $PID

Mais cela est compliqué (et ne fonctionne pas vraiment) car 1) j'ai besoin de veille (sinon le test démarrera avant que le DB ne soit initialisé par le serveur de test) et 2) le test essaiera d'initialiser à nouveau la base (après que le serveur de tests l’a déjà initialisé).

D'autres solutions à cela?

Merci.

Answer 1

Oui, vous avez raison - c'est un problème et il y a un bogue: http: / /code.djangoproject.com/ticket/2879

Justement, vous pourriez alors rencontrer des problèmes multithreads, intentionnellement omis: http://code.djangoproject.com / ticket / 10117 http://code.djangoproject.com/ticket/4513 http://code.djangoproject.com/ticket/3357

Je suis frustré. J'ai donc écrit une bibliothèque qui inclut le démarrage du serveur en direct dans un thread séparé, puis le nettoyage suivant: http://devel.almad.net/trac/django-sane-testing/ . Il démarre également le serveur de Django multithread par le monkeypatchatch d’exécution et vous pouvez utiliser cherrypy http à la place (ce qui est mieux de toute façon).

Le seul problème est qu’il vous oblige à utiliser nose comme framework de test (compatibilité ascendante à 100% avec unittest standard, mais si vous utilisez déjà autre chose ...). Vous pouvez alors simplement utiliser --with-django et --with-djangoliveserver / - with-cherrypyliveserver. Aucune idée de comment cela fonctionnera avec l'épargne.

Attention:

• S'il vous plaît, ne boguez pas les développeurs Django avec des rapports de bogues, vous êtes autonome
• Windmill fournit la même solution. Si vous utilisez Windmill, vous aurez probablement des conflits de ports