Aula 17 – Testes automatizados – test-driven development

More videos
Views
   

Criando uma primeira aplicação com Django e mysql

Testes automatizados – test-driven development

https://docs.djangoproject.com/pt-br/1.11/intro/tutorial05/

Testes automatizados

Testes automatizados – test-driven development

Apresentando testes automatizados

O que são testes automatizados?

Testes são rotinas simples que checam o funcionamento do seu código.

  • Testes 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 foi feito anteriormente na parte 2 do tutorial, 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.

Por que criar testes?

Você pode achar que já aprendeu o suficiente de Python/Django, e ter ainda mais coisas para aprender e fazer, pode parecer exagerado e talvez desnecessário. Afinal, nossa aplicação de enquetes está funcionando muito bem.

Passar pelo trabalho de criar testes automatizados não vai fazê-la funcionar melhor.

A aplicação de enquete ilustrada nesse tutorial é muito simples, mas, se você vai criar um projeto mais complexo, será necessário implementar testes automatizados, para garantir que todos os componentes da sua app trabalharão adequadamente.

Além disso, os testes vão melhorar sua produtividade e você vai ganhar tempo.

Até 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.

Uma mudança em qualquer desses componentes pode trazer consequências inesperadas no comportamento da aplicação. Verificar que ainda ‘parece funcionar’ poderia significar rodar todas as funcionalidades do seu código com variações diferentes dos dados do seu teste, só pra ter certeza que você não tem nada quebrado, e isso não é um bom uso do seu tempo.

Isso é 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.

Às vezes testes automatizados podem parecer uma tarefa que vai piorar a sua produtividade e criatividade, particularmente quando você sabe que seu código está funcionando corretamente, mas, 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.

Testes não só identificam problemas, mas também os previnem.

É um erro pensar nos testes simplesmente como um aspecto negativo do desenvolvimento.

Sem testes, o objetivo ou comportamento desejado de uma aplicação pode não ser tão claro. Mesmo sendo seu próprio código, algumas vezes você vai se encontrar tentando entender exatamente o que você quis fazer.

Testes mostram seu código por dentro, e quando algumas coisas saem errado, eles revelam parte do erro.

Testes fazem seu código mais atraente.

Você pode criar uma parte importante no software, mas você vai encontrar muitos outros desenvolvedores que vão simplesmente ignorar o seu código se você não tiver criado testes, sem testes, não há confiança.

Jacob Kaplan-Moss, um dos primeiros desenvolvedores do Django diz “Código sem testes é quebra de design”.

Assim, esses outros desenvolvedores procuram ver os testes do seu software antes de levar seu código a sério, e isso é uma outra razão para você iniciar a escrita dos testes.

Testes ajudam as equipes a trabalharem juntos.

Os 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, você deve ser bom em escrever testes!

Alguns programadores seguem uma disciplina chamada “test-driven development”, desenvolvimento orientado por teste, eles escrevem seus testes antes de escrever o código.

Isso talvez pareça não intuitivo, mas na verdade é: um teste descreve um problema, depois então, cria-se um código para resolver esse problema.

Em geral, um programador novato e sem experiência pensa em criar um código para resolver algum problema, para depois, testar o código pra verificar eventuais erros.

À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 uma tarefa 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.

Antes de começar a escrever os testes coloque no arquivo mysite/urls.py


from django.conf.urls import include, url
from django.contrib import admin

urlpatterns = [
    url(r'^polls/', include('polls.urls')),
    url(r'^admin/', admin.site.urls),
]

 

Para baixar o código como está até agora, acesse o meu github no link abaixo:
https://github.com/toticavalcanti/django_course/tree/create_form

AULA  16

AULA  18

Obrigado

Até a próxima

Increva-se

Inscreva-se agora e receba um e-mail assim que eu publicar novo conteúdo.

Concordo em me inscrever no blog Código Fluente

Você poderá cancelar sua inscrição a qualquer momento.

(Visited 6 times, 1 visits today)
About The Author
-

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>