Voglio scrivere un test unitario per un comando manage.py Django che esegue un'operazione di back-end su una tabella di database. Come invoco il comando di gestione direttamente dal codice?
Non voglio eseguire il comando sulla shell del sistema operativo da tests.py perché non riesco a utilizzare l'ambiente di test impostato utilizzando il comando manage.py (database di test, posta in uscita fittizia di test, ecc ...)
Risposte:
Il modo migliore per testare queste cose - estrarre le funzionalità necessarie dal comando stesso alla funzione o classe autonoma. Aiuta a sottrarre "roba di esecuzione dei comandi" e scrivere test senza requisiti aggiuntivi.
Ma se per qualche motivo non riesci a disaccoppiare il comando del modulo logico puoi chiamarlo da qualsiasi codice usando il metodo call_command in questo modo:
from django.core.management import call_command
call_command('my_command', 'foo', bar='baz')
call_command('check'), per assicurarsi che i controlli di sistema stiano passando, in un test.
Anziché eseguire il trucco call_command, è possibile eseguire l'attività eseguendo:
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_commandbisogno di caricare l'applicazione testata INSTALLED_APPS. Tra il dover caricare l'app solo a scopo di test e l'utilizzo di questo, ho scelto questo.
call_commandè probabilmente quello che la maggior parte delle persone dovrebbe provare prima. Questa risposta mi ha aiutato a risolvere un problema in cui dovevo passare i nomi di tabella unicode al inspectdbcomando. python / bash interpretavano gli argomenti della riga di comando come ascii, e questo stava bombardando la get_table_descriptionchiamata nel profondo di Django.
il seguente codice:
from django.core.management import call_command
call_command('collectstatic', verbosity=3, interactive=False)
call_command('migrate', 'myapp', verbosity=3, interactive=False)
... è uguale ai seguenti comandi digitati nel terminale:
$ ./manage.py collectstatic --noinput -v 3
$ ./manage.py migrate myapp --noinput -v 3
Vedi l' esecuzione dei comandi di gestione dai documenti di django .
La documentazione di Django sul comando call_ non riesce a menzionare che outdeve essere reindirizzata sys.stdout. Il codice di esempio dovrebbe essere:
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())
Basandomi sulla risposta di Nate ho questo:
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_with
Uso:
from myapp.management import mycommand
cmd_runner = make_test_wrapper_for(mycommand)
cmd_runner("foo", "bar")Il vantaggio qui è che se hai utilizzato opzioni aggiuntive e OptParse, questo risolverà il problema per te. Non è del tutto perfetto - e non convoglia ancora gli output - ma utilizzerà il database di test. È quindi possibile verificare gli effetti del database.
Sono sicuro che l'uso del modulo simulato di Micheal Foords e anche il ricablaggio dello stdout per la durata di un test significherebbe che potresti ottenere qualcosa in più anche da questa tecnica - testare l'output, le condizioni di uscita ecc.