Talvez você ja tenha se perguntado alguma vez se a aplicação que você criou, ou que tenha trabalhado junto com outra equipe, se é robusta o suficiente para “aguentar os trancos” da produção.
Bem, hoje vamos falar de algumas características que ao meu ver são necessárias para que sua aplicação, seja mobile, desktop ou web, seja resiliente e entregue seu real valor dentro de um ambiente de produção.
Em resumo, o que vou explicar é o que é preciso fazer além das funções e classes que compõem seu código.
Se há uma coisa que aprendi nesta vida de desenvolvimento, é que código bom sem testes, não existe…
Praticamente tudo que vou considerar se resume a testes. Dos mais variados tipos.
A receita para uma aplicação robusta e resiliente é a criação de testes.
Para isso temos inúmeros tipos. Desde comportamentais, que simulam a utilização de um usuário, testes de versão beta, que utilizam usuários reais para descoberta de bugs. testes de integração, de resiliência ou capacidade.
Os primeiros a serem feitos são os testes unitários. Como desenvolvedor, estes são os seus maiores amigos para guiarem o desenvolvimento.
O que seriam testes de unidade, ou unitários? Como o nome diz… eles testam UMA coisa apenas. Se a função soma um valor a outro, o teste para isso só vai verificar se a função está retorna 6 quando os parâmetros são 2 e 4. Ou que retorna 7 se os parâmetros forem 1, 2 e 4. E assim por diante.
def soma(a, b, *args):
total = a + b
for i in args:
total += i
return total
def teste_soma_dois_valores():
assert soma(4, 2) == 6
print("teste com dois valores passou")
def teste_soma_tres_valores():
assert soma(3, 2, 2) == 7
print("teste com três valores passou")
if __name__ == "__main__":
teste_soma_dois_valores()
teste_soma_tres_valores()
Óbvio que este é um exemplo muito simples, algumas funções exigem lógicas e percursos mais complexos, que envolvem outras funções. Para isso, existem algumas técnicas como mock, fixtures ou factories.
O teste unitário é a base para o TDD. É o mínimo a se entregar quando se desenvolve qualquer código. É o teste mais básico do desenvolvimento. É o chão de fabrica, aquele que tá lado a lado quando você está desenvolvendo.
Testes de integração estão um nível acima do unitário. Eles têm o propósito de verificar alguns componentes de forma mais unida, já começando a deixar de se importar com o “COMO” e olhando mais “O QUE” o componente faz. Em outras palavras e fazendo jus ao seu próprio nome, eles testam a INTEGRAÇÃO entre os métodos.
Eu costumo usar testes de integração para verificar consultas de api, por exemplo. Testo para verificar se as consultas de API tem um retorno esperado.
Percebam que neste caso, o teste de integração não se preocupa com o que acontece dentro do sistema da API e sim em sua resposta, em seu comportamento.
Teste ponta a ponta é um outro teste importante. Ele é o terceiro que eu considero no pipe de desenvolvimento.
Geralmente ele roda em ambiente de staging. Se você não sabe o que é staging, recomendo este outro artigo.
O teste ponta a ponta é uma simulação de um usuário na plataforma. Por exemplo, se a minha aplicação é uma plataforma de agendamento de consultas médicas. O teste ponta a ponta irá simular um usuário entrar no site, se cadastrar, verificar o email e agendar um horário.
Uma das ferramentas que podem ser utilizadas para isso é o Selenium.
Esta pirâmide é uma forma de enxergar a pilha de testes. Os testes de unidade são a base do seu desenvolvimento e são feitos em maior quantidade. O ideal é ter um ou mais testes para cada função, testando todos os possíveis valores e a resposta esperada da função.
Os testes de integração são em menor quantidade que os unitários. Pois como envolvem a relação entre objetos e métodos, não precisam ser tão granulares quanto os unitários.
Por último os testes end-to-end ou ponta a ponta, são o topo da pirâmide, pois analisam a aplicação como um todo. E claro, tem a menor granularidade de todos.
Agora você pode me perguntar, mas quem faz isso tudo é o desenvolvedor?
E eu te respondo, DEPENDE! Claro, resposta mais óbvia. Mas depende da composição da sua equipe.
Se a equipe for pequena, pode ser que todos sejam os responsáveis por todos os testes. Mas é comum que quando a aplicação cresce, algumas pessoas fiquem dedicadas aos testes. São profissionais que chamamos de Quality Assurance. Ou mais conhecidos como analistas de QA.
Eles são os profissionais que criam as condições e os requisitos para a aplicação.
Além dos testes que mencionei, há alguns outros que fazem parte de uma pipe de desenvolvimento.
Testes de exaustão verificam o quanto sua aplicação consegue suportar em requisições.
Testes de invasão, ou em inglês, pentests (penetration tests), não traduzidos ao pé da letra porque o brasileiro iria fazer piada com isso.
Estes pentests servem para verificar vulnerabilidades de dados na sua aplicação. O que pode ser encontrado por uma pessoa mal intencionada e causar danos. Como roubar e/ou apagar dados importantes e sigilosos. Ou derrubar aplicações, modificar sistemas, desviar acessos, etc. O céu é o limite para a maldade.
Você pode ouvir também alguns termos de testes caixa preta e caixa branca.
Caixa preta ou blackbox é original das aeronaves. Que carregam informações dentro de uma caixa robusta chamada caixa preta. Como você não sabe o que está la dentro, este termo passou a ser conhecido como algo que você sabe que funciona, mas não sabe como funciona em seu interior. Como um motor de carro, por exemplo.
Você sabe como ligar, e operar. Porém, não sabe como as coisas funcionam dentro do motor.
Assim, voltando para os testes. Caixa preta é quando não sabe como a aplicação funciona, mas verifica O QUE ela devolve. Eu considero os testes caixa preta a partir dos testes ponta a ponta e dependendo dos testes, os testes de integração.
Os testes de caixa branca São portando aqueles que você sabe o que está no interior da aplicação. Você testa o COMO sua aplicação processa as informações.
Saber esta pirâmide de testes facilita voce discutir o pipeline de desenvolvimento com sua equipe
Tem alguma dúvida? Deixe nos comentários. Ficou faltando algum teste que não mencionei? Deixe aqui nos comentários.
