Eu quero escrever um teste de unidade para um comando Django manage.py que faz uma operação de back-end em uma tabela de banco de dados. Como eu chamaria o comando de gerenciamento diretamente do código?
Não quero executar o comando no shell do sistema operacional a partir de tests.py porque não posso usar o ambiente de teste configurado usando o manage.py test (banco de dados de teste, caixa de saída de email fictícia de teste, etc ...)
Respostas:
A melhor maneira de testar essas coisas - extrair a funcionalidade necessária do próprio comando para a função ou classe autônoma. Ajuda a abstrair do "material de execução de comando" e escrever o teste sem requisitos adicionais.
Mas se por algum motivo você não conseguir dissociar o comando do formulário lógico, poderá chamá-lo de qualquer código usando o método call_command como este:
from django.core.management import call_command
call_command('my_command', 'foo', bar='baz')call_command('check'), para garantir que as verificações do sistema sejam aprovadas em um teste.
Em vez de executar o truque call_command, você pode executar sua tarefa executando:
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_commandprecisa que o aplicativo testado seja carregado INSTALLED_APPS. Entre ter que carregar o aplicativo apenas para fins de teste e usar isso, eu escolhi isso.
call_commandé provavelmente o que a maioria das pessoas deve tentar primeiro. Esta resposta me ajudou a solucionar um problema em que eu precisava passar nomes de tabelas unicode para o inspectdbcomando. python / bash estava interpretando argumentos da linha de comando como ascii, e isso estava bombardeando a get_table_descriptionchamada profundamente no django.
o seguinte código:
from django.core.management import call_command
call_command('collectstatic', verbosity=3, interactive=False)
call_command('migrate', 'myapp', verbosity=3, interactive=False)... é igual aos seguintes comandos digitados no terminal:
$ ./manage.py collectstatic --noinput -v 3
$ ./manage.py migrate myapp --noinput -v 3A documentação do Django no call_command falha ao mencionar que outdeve ser redirecionada para sys.stdout. O código de exemplo deve ser:
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())Com base na resposta de Nate, tenho o seguinte:
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_withUso:
from myapp.management import mycommand
cmd_runner = make_test_wrapper_for(mycommand)
cmd_runner("foo", "bar")A vantagem aqui é que, se você usou opções adicionais e o OptParse, isso resolverá o problema. Não é perfeito - e ainda não canaliza resultados -, mas usará o banco de dados de teste. Você pode testar os efeitos do banco de dados.
Estou certo de que o uso do módulo de simulação Micheal Foords e também a reconexão do stdout durante a duração de um teste significariam que você também poderia aproveitar um pouco mais dessa técnica - teste a saída, as condições de saída etc.