Je souhaite écrire un test unitaire pour une commande Django manage.py qui effectue une opération de backend sur une table de base de données. Comment appeler la commande de gestion directement à partir du code?
Je ne veux pas exécuter la commande sur le shell du système d'exploitation à partir de tests.py car je ne peux pas utiliser l'environnement de test configuré à l'aide de manage.py test (base de données de test, boîte d'envoi d'e-mail factice de test, etc.)
Réponses:
La meilleure façon de tester de telles choses - extraire les fonctionnalités nécessaires de la commande elle-même vers une fonction ou une classe autonome. Il permet de faire abstraction des «trucs d'exécution de commande» et d'écrire des tests sans exigences supplémentaires.
Mais si, pour une raison quelconque, vous ne pouvez pas découpler la commande de formulaire logique, vous pouvez l'appeler à partir de n'importe quel code en utilisant la méthode call_command comme celle-ci:
from django.core.management import call_command
call_command('my_command', 'foo', bar='baz')
call_command('check'), pour s'assurer que les vérifications du système sont réussies, dans un test.
Plutôt que de faire l'astuce call_command, vous pouvez exécuter votre tâche en faisant:
from myapp.management.commands import my_management_task
cmd = my_management_task.Command()
opts = {} # kwargs for your command -- lets you override stuff for testing...
cmd.handle_noargs(**opts)
call_commandbesoin de l'application testée pour être chargée INSTALLED_APPS. Entre devoir charger l'application uniquement à des fins de test et l'utiliser, j'ai choisi ceci.
call_commandest probablement ce que la plupart des gens devraient essayer en premier. Cette réponse m'a aidé à contourner un problème où je devais passer des noms de table Unicode à la inspectdbcommande. python / bash interprétaient les arguments de ligne de commande comme ascii, et cela bombardait l' get_table_descriptionappel profondément dans django.
le code suivant:
from django.core.management import call_command
call_command('collectstatic', verbosity=3, interactive=False)
call_command('migrate', 'myapp', verbosity=3, interactive=False)... est égal aux commandes suivantes tapées dans le terminal:
$ ./manage.py collectstatic --noinput -v 3
$ ./manage.py migrate myapp --noinput -v 3Voir l' exécution des commandes de gestion à partir de la documentation django .
La documentation Django sur la commande call_command ne mentionne pas qui outdoit être redirigé vers sys.stdout. L'exemple de code doit lire:
from django.core.management import call_command
from django.test import TestCase
from django.utils.six import StringIO
import sys
class ClosepollTest(TestCase):
def test_command_output(self):
out = StringIO()
sys.stdout = out
call_command('closepoll', stdout=out)
self.assertIn('Expected output', out.getvalue())En m'appuyant sur la réponse de Nate, j'ai ceci:
def make_test_wrapper_for(command_module):
def _run_cmd_with(*args):
"""Run the possibly_add_alert command with the supplied arguments"""
cmd = command_module.Command()
(opts, args) = OptionParser(option_list=cmd.option_list).parse_args(list(args))
cmd.handle(*args, **vars(opts))
return _run_cmd_withUsage:
from myapp.management import mycommand
cmd_runner = make_test_wrapper_for(mycommand)
cmd_runner("foo", "bar")L'avantage ici est que si vous avez utilisé des options supplémentaires et OptParse, cela réglera le problème pour vous. Ce n'est pas tout à fait parfait - et il ne dirige pas encore les sorties - mais il utilisera la base de données de test. Vous pouvez ensuite tester les effets de la base de données.
Je suis sûr que l'utilisation du module simulé Micheal Foords et le recâblage de stdout pendant la durée d'un test signifieraient que vous pourriez aussi tirer un peu plus de cette technique - tester la sortie, les conditions de sortie, etc.