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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
from selenium import webdriver browser = webdriver.Firefox() # Edith ouviu falar sobre um novo aplicativo de tarefas online, é muito legal. Ela vai # Ela acessa a página incial browser.get('http://localhost:8000') # Ela observa o título da página escrito to-do lists assert 'To-Do' in browser.title # Ela é convidada a inserir um item de tarefa imediatamente # Ela digita "Comprar penas de pavão" em uma caixa de texto (é o hobby de Edith # está amarrando iscas de pesca com mosca) # Quando ela pressiona enter, a página é atualizada e agora a página lista # "1: Comprar penas de pavão" como um item de uma lista de tarefas # Ainda há uma caixa de texto convidando-a para adicionar outro item. Ela # digita "Use penas de pavão para fazer uma mosca" (Edith é muito metódica) # A página é atualizada novamente e agora mostra os dois itens em sua lista # Edith se pergunta se o site se lembrará de sua lista. Então ela vê # que o site gerou um URL exclusivo para ela - há alguns # texto explicativo para esse efeito. # Ela visita essa URL - sua lista de tarefas ainda está lá. # Satisfeita, ela volta a dormir browser.quit() |
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.
Deixe um comentário