This tutorial begins where Tutorial 4 left off.\nWe’ve built a web-poll application, and we’ll now create some automated tests\nfor it.
\n\nTestes são rotinas que verificam o funcionamento do seu código.
\nTestes funcionam em diferentes níveis. Alguns testes podem ser aplicados a um pequeno detalhe (um determinado método de um modelo retorna o valor esperado?) enquanto outros examinam o funcionamento global do software (a sequência de entradas do usuário no site produz o resultado desejado?). Isso não é diferente do teste que você fez anteriormente no Tutorial 2, usando o shell para examinar o comportamento de um método, ou executar a aplicação e entrar com um dado para verificar como ele se comporta.
A diferença em testes automatizados é que o trabalho de testar é feito para você pelo sistema. Você cria um conjunto de testes uma vez, e então conforme faz mudanças em sua aplicação, você pode checar se o seu código continua funcionando como você originalmente pretendia, sem ter que gastar tempo executando o teste manualmente.
\nEntão, por que criar testes, e por que agora?
\nVocê pode achar que já tem coisa suficiente no seu prato apenas aprendendo Python/Django, e tendo ainda outra coisa para aprender e fazer pode parecer exagerado e talvez desnecessário. Afinal, nossa aplicação de enquetes está funcionando muito bem agora; passar pelo trabalho de criar testes automatizados não vai fazê-la funcionar melhor. Se criar a aplicação de enquetes é a última coisa que você vai programar em Django, então realmente, você não precisa saber sobre como criar testes automatizados. Mas, se esse não é o caso, agora é uma excelente hora para aprender.
\nAté um certo ponto, ‘verificar que parece funcionar’ será um teste satisfatório. Em uma aplicação mais sofisticada, você pode ter dúzias de interações complexas entre componentes.
\nA change in any of those components could have unexpected consequences on the\napplication’s behavior. Checking that it still ‘seems to work’ could mean\nrunning through your code’s functionality with twenty different variations of\nyour test data to make sure you haven’t broken something - not a good use\nof your time.
\nIsso é verdade especialmente quando testes automatizados poderiam fazer isso pra você em segundos. Se alguma coisa errada acontecer, os testes também ajudarão em identificar o código que está causando o comportamento inesperado.
\nÀs vezes pode parece uma tarefa para afastar você da sua produtividade e criatividade em programar para enfrentar o trabalho nada excitante e glamouroso de escrever testes, particularmente quando você sabe que seu código está funcionando corretamente.
\nNo entanto, a tarefa de escrever testes é muito mais satisfatório do que gastar horas testando sua aplicação manualmente, ou tentando identificar a causa de um problema recém-introduzido.
\nÉ um erro pensar nos testes simplesmente como um aspecto negativo do desenvolvimento.
\nSem testes, o objetivo ou comportamento desejado de uma aplicação pode não ser tão claro. Mesmo quando é seu próprio código, algumas vezes você vai se encontrar bisbilhotando nele tentando descobrir exatamente o que está fazendo.
\nTestes mudam isso; eles mostram seu código por dentro, e quando algumas coisas saem errado, eles revelam parte do erro.
\nYou might have created a brilliant piece of software, but you will find that\nmany other developers will refuse to look at it because it lacks tests; without\ntests, they won’t trust it. Jacob Kaplan-Moss, one of Django’s original\ndevelopers, says “Code without tests is broken by design.”
\nAssim, esses outros desenvolvedores procuram ver os testes do seu software antes de levar a sério, e isso é uma outra razão para você iniciar a escrita dos testes.
\nOs pontos anteriores foram escritos do ponto de vista de um único desenvolvedor mantendo uma aplicação. Aplicações complexas serão mantidas por times. Testes garantem que seus colegas de trabalho não quebrem acidentalmente o seu código (e que você não quebre o deles sem saber). Se você deseja trabalhar como um programador Django, deve ser bom escrevendo testes!
\nHá várias maneiras de abordar a escrita de testes.
\nSome programmers follow a discipline called “test-driven development”; they\nactually write their tests before they write their code. This might seem\ncounter-intuitive, but in fact it’s similar to what most people will often do\nanyway: they describe a problem, then create some code to solve it. Test-driven\ndevelopment formalizes the problem in a Python test case.
\nComumente, um novato em testes irá criar algum código e depois decidir que ele deveria ser testado. Talvez seria melhor escrever alguns testes antes, mas nunca é tarde para começar.
\nÀs vezes é difícil saber por onde devemos começar a escrever testes. Se você tiver escrito milhares de linhas em Python, escolher algo para testar pode não ser fácil. Nesse caso, é interessante escrever seu primeiro teste na próxima vez que você fizer alguma alteração, seja a adição de uma nova função ou correção de um bug.
\nEntão vamos fazer isso a partir de agora.
\nFelizmente, há um pequeno bug na aplicação polls para corrigirmos imediatamente: O método Question.was_published_recently() retorna True se a Question foi publicada dentro do último dia (o que está correto), mas também se o campo pub_date de Question está no futuro (o que certamente não é o caso).
Confirme o bug utilizando shell para verificar o método numa questão em que a data encontra-se no futuro:
Linux / macOS
$ python manage.py shell\nWindows
...\\> py manage.py shell\n>>> import datetime\n>>> from django.utils import timezone\n>>> from polls.models import Question\n>>> # create a Question instance with pub_date 30 days in the future\n>>> future_question = Question(pub_date=timezone.now() + datetime.timedelta(days=30))\n>>> # was it published recently?\n>>> future_question.was_published_recently()\nTrue\nDesde que coisas no futuro não são ‘recent’, isto é claramente um erro.
\nO que nós fizemos no shell para testar o problema é exatamente o que podemos fazer em um teste automatizado, então vamos voltar para o teste automatizado
Um lugar convencional para os testes da aplicação é o arquivo tests.py; o sistema de testes irá encontrar automaticamente todos os testes que estiverem em qualquer arquivo cujo o nome comece com test.
Coloque o seguinte código no arquivo tests.py na aplicação polls:
polls/tests.pyimport datetime\n\nfrom django.test import TestCase\nfrom django.utils import timezone\n\nfrom .models import Question\n\n\nclass QuestionModelTests(TestCase):\n\n def test_was_published_recently_with_future_question(self):\n """\n was_published_recently() returns False for questions whose pub_date\n is in the future.\n """\n time = timezone.now() + datetime.timedelta(days=30)\n future_question = Question(pub_date=time)\n self.assertIs(future_question.was_published_recently(), False)\nAqui criamos uma subclasse de django.test.TestCase com um método que cria uma instância de Question com uma pub_date no futuro. Então verificamos a saída de was_published_recently() - o qual deve ser False.
No terminal, podemos rodar nosso teste:
\nLinux / macOS
$ python manage.py test polls\nWindows
...\\> py manage.py test polls\nE você verá algo como:
\nCreating test database for alias 'default'...\nSystem check identified no issues (0 silenced).\nF\n======================================================================\nFAIL: test_was_published_recently_with_future_question (polls.tests.QuestionModelTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n File "/path/to/mysite/polls/tests.py", line 16, in test_was_published_recently_with_future_question\n self.assertIs(future_question.was_published_recently(), False)\nAssertionError: True is not False\n\n----------------------------------------------------------------------\nRan 1 test in 0.001s\n\nFAILED (failures=1)\nDestroying test database for alias 'default'...\nO que ocorreu foi o seguinte:
\nmanage.py test polls looked for tests in the polls application
ele encontrou uma subclass da classe django.test.TestCase
ele cria um banco de dados especial com o propósito de teste
ele procurou por métodos de test - aquele cujo nome começam com test
em test_was_published_recently_with_future_question é criado uma instância de Question na qual o campo pub_date está 30 dias no futuro
… e usando o método assertIs(), descobrimos que was_published_recently() retorna True, mas queremos que retorne False
O teste nos informa que teste falhou e até mesmo a linha na qual a falha ocorreu.
\nNós sabemos onde o problema está. “Question.was_published_recently()” deveria retornar “False” se “pub_date” está no futuro. Corrija o método no “models.py”, dessa forma ele só retornará “True” se a data também estiver no passado:
\npolls/models.pydef was_published_recently(self):\n now = timezone.now()\n return now - datetime.timedelta(days=1) <= self.pub_date <= now\nexecute e teste novamente
\nCreating test database for alias 'default'...\nSystem check identified no issues (0 silenced).\n.\n----------------------------------------------------------------------\nRan 1 test in 0.001s\n\nOK\nDestroying test database for alias 'default'...\nDepois de identificar um erro, nós escrevemos um teste que demonstra e corrige o erro no código, então o nosso teste passa.
\nMany other things might go wrong with our application in the future, but we can\nbe sure that we won’t inadvertently reintroduce this bug, because running the\ntest will warn us immediately. We can consider this little portion of the\napplication pinned down safely forever.
\nEnquanto estamos aqui, nós podemos nos aprofundar no método was_published_recently(); De fato, seria certamente embaraçoso introduzir um novo bug enquanto arruma outro.
Adicione mais dois métodos de teste na mesma classe, para testá-la melhor.
\npolls/tests.pydef test_was_published_recently_with_old_question(self):\n """\n was_published_recently() returns False for questions whose pub_date\n is older than 1 day.\n """\n time = timezone.now() - datetime.timedelta(days=1, seconds=1)\n old_question = Question(pub_date=time)\n self.assertIs(old_question.was_published_recently(), False)\n\ndef test_was_published_recently_with_recent_question(self):\n """\n was_published_recently() returns True for questions whose pub_date\n is within the last day.\n """\n time = timezone.now() - datetime.timedelta(hours=23, minutes=59, seconds=59)\n recent_question = Question(pub_date=time)\n self.assertIs(recent_question.was_published_recently(), True)\nE agora nós temos 3 testes que confirmam que Question.was_published_recently() retorna valores sensíveis de perguntas do passado, recente e futuro.
Again, polls is a minimal application, but however complex it grows in the\nfuture and whatever other code it interacts with, we now have some guarantee\nthat the method we have written tests for will behave in expected ways.
A aplicação de enquete é bastante indiscriminatória: irá publicar qualquer questão, incluindo aquelas que o campo pub_date está no futuro. Devemos melhorar isso. Definindo um pub_date no futuro deveria fazer com que a Question seja publicada naquele momento, mas que esteja invisível até lá.
When we fixed the bug above, we wrote the test first and then the code to fix\nit. In fact that was an example of test-driven development, but it doesn’t\nreally matter in which order we do the work.
\nEm nosso primeiro teste, focamos no comportamento interno do código. Para este teste, nós queremos checar seu comportamento como seria experienciado por um usuário através de um navegador web.
\nAntes de tentarmos consertar alguma coisa, vamos dar uma olhada nas ferramentas à nossa disposição.
\no Django fornece um test Client para simular um usuário interagindo com o código no nível de view. POdemos usá-lo em tests.py ou memso no shell.
We will start again with the shell, where we need to do a couple of\nthings that won’t be necessary in tests.py. The first is to set up the test\nenvironment in the shell:
Linux / macOS
$ python manage.py shell\nWindows
...\\> py manage.py shell\n>>> from django.test.utils import setup_test_environment\n>>> setup_test_environment()\nsetup_test_environment() installs a template renderer\nwhich will allow us to examine some additional attributes on responses such as\nresponse.context that otherwise wouldn’t be available. Note that this\nmethod does not set up a test database, so the following will be run against\nthe existing database and the output may differ slightly depending on what\nquestions you already created. You might get unexpected results if your\nTIME_ZONE in settings.py isn’t correct. If you don’t remember setting\nit earlier, check it before continuing.
A diante precisamos importar a classe cliente de teste (depois iremos usar a classe django.test.TestCase no tests.py, a qual traz seu próprio cliente, então isso não será necessário):
>>> from django.test import Client\n>>> # create an instance of the client for our use\n>>> client = Client()\nCom isso pronto, podemos pedir que o cliente faça algum trabalho para a gente:
\n>>> # get a response from '/'\n>>> response = client.get('/')\nNot Found: /\n>>> # we should expect a 404 from that address; if you instead see an\n>>> # "Invalid HTTP_HOST header" error and a 400 response, you probably\n>>> # omitted the setup_test_environment() call described earlier.\n>>> response.status_code\n404\n>>> # on the other hand we should expect to find something at '/polls/'\n>>> # we'll use 'reverse()' rather than a hardcoded URL\n>>> from django.urls import reverse\n>>> response = client.get(reverse('polls:index'))\n>>> response.status_code\n200\n>>> response.content\nb'\\n <ul>\\n \\n <li><a href="/polls/1/">What's up?</a></li>\\n \\n </ul>\\n\\n'\n>>> response.context['latest_question_list']\n<QuerySet [<Question: What's up?>]>\nA lista de enquete mostra enquetes que não estão publicadas ainda (isto é aqueles que tem um ``pub_date``no futuro). Vamos concertar isso.
\nNo Tutorial 4 nós introduzimos o class-based views, baseado no ListView:
polls/views.pyclass IndexView(generic.ListView):\n template_name = 'polls/index.html'\n context_object_name = 'latest_question_list'\n\n def get_queryset(self):\n """Return the last five published questions."""\n return Question.objects.order_by('-pub_date')[:5]\nPrecisamos fazer uma adição no método get_queryset() e alterá-lo de modo que ele verifique também a data comparando com timezone.now(). Antes precisamos adicionar uma importação:
polls/views.pyfrom django.utils import timezone\ne então devemos fazer uma adição ao método get_queryset como a seguir:
polls/views.pydef get_queryset(self):\n """\n Return the last five published questions (not including those set to be\n published in the future).\n """\n return Question.objects.filter(\n pub_date__lte=timezone.now()\n ).order_by('-pub_date')[:5]\nQuestion.objects.filter(pub_date__lte=timezone.now()) retorna um queryset contendo Questions cujo o pub_date é menor ou igual a - que quer dizer, anterior ou igual a - timezone.now.
Agora você pode se certificar se isso se comporta como esperado executando runserver, carregando o site no seu navegador, criando Questions com datas no passado e no futuro, e verificando que somente aqueles que foram publicados são listados. Você não quer ter que fazer isso toda vez que fizer uma alterações que possa afetar isso - então vamos também criar um teste, baseado no nossa sessão shell acima.
Adicione o seguinte a “polls/tests.py”:
\npolls/tests.pyfrom django.urls import reverse\ne nós vamos criar uma função de atalho para criar perguntas assim como uma nova classe de teste:
\npolls/tests.pydef create_question(question_text, days):\n """\n Create a question with the given `question_text` and published the\n given number of `days` offset to now (negative for questions published\n in the past, positive for questions that have yet to be published).\n """\n time = timezone.now() + datetime.timedelta(days=days)\n return Question.objects.create(question_text=question_text, pub_date=time)\n\n\nclass QuestionIndexViewTests(TestCase):\n def test_no_questions(self):\n """\n If no questions exist, an appropriate message is displayed.\n """\n response = self.client.get(reverse('polls:index'))\n self.assertEqual(response.status_code, 200)\n self.assertContains(response, "No polls are available.")\n self.assertQuerysetEqual(response.context['latest_question_list'], [])\n\n def test_past_question(self):\n """\n Questions with a pub_date in the past are displayed on the\n index page.\n """\n question = create_question(question_text="Past question.", days=-30)\n response = self.client.get(reverse('polls:index'))\n self.assertQuerysetEqual(\n response.context['latest_question_list'],\n [question],\n )\n\n def test_future_question(self):\n """\n Questions with a pub_date in the future aren't displayed on\n the index page.\n """\n create_question(question_text="Future question.", days=30)\n response = self.client.get(reverse('polls:index'))\n self.assertContains(response, "No polls are available.")\n self.assertQuerysetEqual(response.context['latest_question_list'], [])\n\n def test_future_question_and_past_question(self):\n """\n Even if both past and future questions exist, only past questions\n are displayed.\n """\n question = create_question(question_text="Past question.", days=-30)\n create_question(question_text="Future question.", days=30)\n response = self.client.get(reverse('polls:index'))\n self.assertQuerysetEqual(\n response.context['latest_question_list'],\n [question],\n )\n\n def test_two_past_questions(self):\n """\n The questions index page may display multiple questions.\n """\n question1 = create_question(question_text="Past question 1.", days=-30)\n question2 = create_question(question_text="Past question 2.", days=-5)\n response = self.client.get(reverse('polls:index'))\n self.assertQuerysetEqual(\n response.context['latest_question_list'],\n [question2, question1],\n )\nVejamos algumas delas mais de perto.
\nO primeiro é uma função de atalho para questão, create_question, para retirar algumas repetições do processo de criar questões.
test_no_questions não cria nenhuma questão, mas verifica a mensagem:”Nenhuma enquete disponível.” e verifica que latest_question_list está vazia. Note que a classe django.test.TestCase fornece alguns métodos adicionais de assertividade. Nestes exemplos nós usamos assertContains() e assertQuerysetEqual().
Em test_past_question, criamos uma questão e verificamos se esta aparece na lista.
Em test_future_question, nós criamos uma pub_date no futuro. O banco de dados é resetado para cada método de teste, quer dizer que a primeira questão não está mais lá, então novamente o index não deve ter nenhuma questão.
E assim por diante. De fato, estamos usando os testes para contar uma história de entradas no site de administração e da experiencia do usuário, e verificando se para cada estado e para cada nova alteração no estado do sistema, o resultado esperado é publicado.
\nDetailViewLink para este cabeçalho#O que temos funciona bem; Porém, mesmo quando questões futuras não aparecem no * index*, os usuários ainda podem acessá-las se eles conhecem ou adivinham a URL correta. Então precisamos adicionar uma regra similar ao DetailView:
polls/views.pyclass DetailView(generic.DetailView):\n ...\n def get_queryset(self):\n """\n Excludes any questions that aren't published yet.\n """\n return Question.objects.filter(pub_date__lte=timezone.now())\nWe should then add some tests, to check that a Question whose pub_date\nis in the past can be displayed, and that one with a pub_date in the future\nis not:
polls/tests.pyclass QuestionDetailViewTests(TestCase):\n def test_future_question(self):\n """\n The detail view of a question with a pub_date in the future\n returns a 404 not found.\n """\n future_question = create_question(question_text='Future question.', days=5)\n url = reverse('polls:detail', args=(future_question.id,))\n response = self.client.get(url)\n self.assertEqual(response.status_code, 404)\n\n def test_past_question(self):\n """\n The detail view of a question with a pub_date in the past\n displays the question's text.\n """\n past_question = create_question(question_text='Past Question.', days=-5)\n url = reverse('polls:detail', args=(past_question.id,))\n response = self.client.get(url)\n self.assertContains(response, past_question.question_text)\nDevemos adicionar um método similar ao get_queryset ao ResultsView e criar uma nova classe de teste para essa “view”. Isso será muito parecido com o que criamos há pouco; defato terá muitas repetições.
Podemos também melhorar nossa aplicação de várias outras maneiras, adicionando testes no caminho. Por exemplo é estranho que Questions possam ser publicadas no site sem que tenham Choices. Então, nossas “views” podem verificar isso, e excluir tais Questions. Nossos testes podem criar uma Question sem Choices e então testar que não estão publicadas, também criar uma Question parecida com Choices, e testar se estão publicadas.
Talvez usuários registrados no admin devam ser permitidos a ver Questions não publicadas, mas não os visitantes comuns. Denovo: independente da necessidade a serem adicionadas ao software para que isso seja realizado, isso deve ser acompanhado por um teste, não importando se você escreve o teste primeiro e então faz o código para passar no teste, ou escreva o código da lógica primeiro e então escreva o teste para fazer a prova.
Em um certo ponto, você precisará olhar seus testes e se perguntar se o seu código está sofrendo de inchaço de testes, o que nos trás a:
\nPode parecer que nossos testes estão crescendo fora de controle. Nessa taxa teremos logo mais código nos testes do que em nossa aplicação, e a repetição não é muito estética, comparado a concisa elegância do resto do nosso código.
\nIsso não importa. Deixe eles crescerem. Por boa parte do tempo, você pode escrever um teste uma vez e então esquecer dele. Ele vai continuar a executar sua função útil enquanto você continua a escrever seu programa.
\nAlgumas vezes os testes precisarão ser atualizados. Suponha que emendamos nossas “views” para que somente Questions``com ``Choices são publicadas. Neste caso, muitos dos nossos testes existentes irão falahar - nos dizendo exatamente quais testes precisam ter ajustes para que sejam atualizados, assim que os próprios testes auxiliam na manutenção deles mesmos.
Na pior das hipóteses, ao continuar a desenvolver, você talvez encontre alguns tests que são reduntantes agora. Mesmo isso não é um problema; em testes redundância é uma boa coisa.
\nEnquanto seus testes estiverem organizados sensatamente, eles não vão se tornar desorganizados. Boas práticas incluem ter:
\num “TestClass” separado para cada modelo ou view
um método de teste separado para cada conjunto de condições que você quer testar
nomes de métodos de teste que descrevem a sua função
Esse tutorial apenas introduz alguns conceitos básicos de testes. Há muito mais do que você pode fazer, e uma série de ferramentas muito úteis à sua disposição para conseguir algumas coisas muito inteligentes.
\nPor exemplo, enquanto nossos testes aqui tem coberto algumas lógicas internas de um modelo e a informação publicada nas nossas “views”, você pode usar um framework para navegador como o Selenium para testar a maneira como seu HTML é processado de verdade pelo navegador. Isso permite a você testar não somente o comportamento do seu código Django, mas também, por exemplo, do seu JavaScript. É bem legal ver seus testes iniciarem um navegador, e começar a interagir com seu site, como se fosse um ser humano guiando! O Django inclue a LiveServerTestCase para facilitar a integração com ferramentas como o Selenium.
Se você tem uma aplicação complexa, você pode querer rodar testes automaticamente com cada commit pelo propósito de integração contínua, e o próprio controle de qualidade - ao menos parcialmente - é automatizado.
\nUma boa forma de encontrar partes não testadas de sua aplicação é verificar a cobertura de código. Isto também ajuda a identificar códigos frágeis ou mesmo morto. Se você não pode testar um pedaço do código, isso normalmente significa que o código precisa ser refatorado ou removido. Cobertura vai ajudar a identificar código morto. Veja Integration with coverage.py para mais detalhes.
\nTestes no django tem informações sobre testes.
\nPara maiores detalhes sobre testing, veja Testando no Django.
\nQuando estiver confortável testando “views” Django, leia: doc:parte 6 deste tutorial</intro/tutorial06> para aprender sobre gerenciamente de arquivos estáticos.
\n