5.1 Isolamento dos Testes Funcionais
Ao encerrarmos o capítulo anterior, nossa aplicação apresentava um pequeno problema que era o acúmulo de itens na lista em execuções sucessivas dos casos de teste. Outro inconveniente que temos em nosso código de testes são os time.sleeps. Durante este capítulo iremos deixar um pouco de lado no desenvolvimento do código da aplicação para nos concentrarmos na melhoria do nosso conjunto de teste funcional.
Nesta seção abordaremos o isolamento dos testes e como eliminar as repetições de inclusão de itens na lista durante execuções sucessivas dos testes. Na Seção 5.2 vamos tratar da questão de sincronização.
O framework unittest oferece métodos que nos permitem executar ações antes ou após cada caso de teste, são os métodos setUp e tearDown, respectivamente. Poderíamos utilizá-los para fazer, antes de cada teste, colocar o sistema em um estado conhecido válido e, posteriormente, limpar os dados produzidos durante a execução de um teste. Entretanto, o Django oferece uma classe de teste, denominada LiveServerTestCase que nos proporciona recursos semelhantes aqueles utilizados nos testes unitários, ou seja, do isolamento dos testes em execuções sucessivas. Essa classe é responsável por criar, automaticamente, um banco de dados de teste.
Testes derivados de LiveServerTestCase esperam ser executados pelo executor de testes do Django e, para isso precisamos reorganizar os arquivos contendo os testes para indicar ao Djando qual conjunto de teste desejamos executar em dado momento. Desse modo, vamos criar uma pasta para acomodar nossos testes funcionais um nível abaixo de nosso diretório de trabalho. Tudo que o Django necessita é uma pasta com um arquivo __init__.pydentro dela.
(superlists) tdd@mlp:~/superlists/superlists$ mkdir functional_tests
(superlists) tdd@mlp:~/superlists/superlists$ touch functional_tests/__init__.pyEm seguida, como nosso código está sob controle de versão, podemos utilizar os comandos do Git para movimentação de arquivos conforme abaixo:
(superlists) tdd@mlp:~/superlists/superlists$ git mv functional_tests.py functional_tests/tests.py
(superlists) tdd@mlp:~/superlists/superlists$ git status
No ramo master
Your branch is up to date with 'origin/master'.
Mudanças a serem submetidas:
(use "git restore --staged <file>..." to unstage)
renamed: functional_tests.py -> functional_tests/tests.py
Arquivos não monitorados:
(utilize "git add <arquivo>..." para incluir o que será submetido)
functional_tests/__init__.pyCom essa alteração, functional_tests.py passou a ser functional_tests/tests.py. O conteúdo do novo arquivo também precisa ser alterado para fazer uso da classe LiveServerTestCase, conforme abaixo.
Basicamente, incluímos a dependência de LiveServerTestCase (linha 1), modificamos a URL utilizada na linha 26 de self.browser.get(http://localhost:8000/) para self.browser.get(self.live_server_url), que identifica corretamente a URL e a porta relacionada com o servidor de teste. Além disso, as linhas de código abaixo podem ser removidas do servidor de teste, pois a execução dos mesmos se dará via manage.py.
Com essas alterações, a execução dos testes funcionais passa a ser realizadas agora da seguinte forma:
Observe que agora, ao executa os testes, o Django cria uma base auxiliar apenas para a execução dos testes, que é destruída no encerramento dos testes, conforme mensagens nas linhas 2 e 16, respectivamente.
Antes de continuarmos, vamos colocar nosso código e suas alterações no controle de verão:
Last updated
Was this helpful?