Usando um Teste Funcional para Escopo Mínimo

Viable App

Testes que utilizam Selenium são feitos em um navegador real, então vamos ver como as funções de aplicações são vistas na visão do usuário. Isto que chamamos de testes funcionais (TF).

Isso significa que um TF pode ser uma espécie de especificação da sua aplicação. Isso costuma-se chamar de User Story, isso é como o usuário trabalha com um recurso particular e como o app deveria responder.

Terminologia:

Teste Funcional == Teste Aceitável = Teste de Ponta a Ponta

Podemos chamar de testes funcionais, algumas pessoas preferem chamar de testes aceitáveis, ou teste de ponta a ponta.

O ponto principal desse tipo de teste é ver como todas as funções da aplicação responde. Outro termo é a caixa preta de teste, dessa parte não sabemos de nada porque não sabemos como o sistema funciona internamente.

TFs deveriam ser uma história que qualquer pessoa pudesse ler e entender. Nós podemos fazer isso por meio de comentários no código.

Quando criamos um TF, nós podemos escrever comentários primeiros, para capturar o ponto principal da User Story.

Sendo assim, fica legível para todos e mais fácil para discutir funcionalidades e recursos do seu app.

TDD e metodologia ágil de software muitas vezes trabalham juntas, e produzem o que se chama o aplicativo mínimo viável.

Qual é a coisa mais simples que podemos construir e ainda ser útil? Vamos construir isso, para podemos testar o mais rápido possível.

Um mínimo viável é um to-do list onde o usuário entra com tarefas que desejam ser realizadas e que o lembre na próxima visita.

Crie um arquivo com o nome funcional_tests.py com o seguinte código:

Vamos Fazer Alguns Comentários…

Quando comecei a programar fazia comentários por toda a parte do meu código. Aí um dia um colega disse-me que comentários são mentirosos. Eu fiquei surpreso. E respondi: “Mas aprendi que comentário é uma boa prática. Não é?”

Com certeza ele exagerou na resposta, mas na verdade ele quis dizer que não faz sentido colocar comentários onde o próprio código já diz o que está sendo feito. E com certeza há locais que um comentário é bem-vindo.

#incremente wibble de 1 em 1

wibble += 1

E quando se diz que comentário são mentirosos é porque quando se atualiza o código ninguém atualiza os comentários.

O ideal é se esforçar para tornar seu código tão legível, para usar bons nomes de variáveis e nomes de funções, e estruturá-lo tão bem que você não precisa mais comentar para explicar o que o código está fazendo. Apenas alguns aqui e ali para explicar o porquê.

Existem outros lugares onde os comentários são muito úteis. Veremos que o Django usa muito nos arquivos que gera para usarmos como uma maneira de sugerir bits úteis de sua API.

E, é claro, usamos comentários para explicar a história do usuário em nossa funcionalidade testes – forçando-nos a fazer uma história coerente com o teste, garante que estamos sempre testando do ponto de vista do usuário.

Você notará que, além de escrever o teste como comentários, estou procurando a palavra “To-Do” em vez de “Django”. Isso significa que esperamos que o teste falhe. Vamos tentar executá-lo.

Primeiro inicie o servidor.

Lembre-se de que o arquivo geckodriver.exe deve está na pasta do teste.

Vamos executar o teste, execute:

É o que chamamos de falha esperada, que na verdade é uma boa notícia não tão boa quanto um teste que passa, mas pelo menos está falhando pelo motivo certo; podemos ter certeza de que escrevemos o teste corretamente.