Testes tem sido o foco quando o tema é qualidade de software. É impossível fazer Continuous Delivery sem testes. Se você já leu o livro ACCELERATE, você deve saber que CD é a chave das organizações de alta performance.
Há vários artigos sobre como escrever testes, TDD a o que é uma pirâmide de testes. Pretendo ter uma conversa um pouco mais abstrata e falar sobre o que você precisa considerar antes de tomar qualquer decisão sobre testes. Após ajudar alguns times desenharem sua estratégia de testes, eu descobri quatro princípios que ajudam times a se manter em dia com sua estratégia e escrever melhores testes. Eles são muito fáceis de recordar pelo acrônimo W.O.R.D.
Os quatro princípios: W.O.R.D.
- It Works (Funciona)
- It Orients the code design (Orienta o design do código)
- It is easy to Refactor (É fácil de Refatorar)
- It is a Debugging tool (É uma ferramenta de Debugging)
Funciona
- It Works
Uma das maiores preocupações com a qualidade do software é entregar um código que funcione sem efeitos colaterais. Qualquer estratégia de teste deve fornecer a segurança de que uma alteração feita que passe em todos os testes possa ser enviada para produção sem medos. Para isso é necessário uma estratégia de teste que cobre o aplicativo em diferentes níveis. Também requer uma equipe que entenda que a qualidade do software é papel de todos.
Desenvolvedoras não devem escrever testes para atingir uma métrica de qualidade. Eles devem entender que isso evitará defeitos e ajudará seus pares a entender o que aquela parte específica do código faz.
Orienta o desenvolvimento e o design do código
- It ORIENTS the development and code design!
Uma boa estratégia de teste deve facilitar o processo de desenvolvimento, você deve ser capaz de testar individualmente pequenos pedaços de uma solução complexa.
Testes fornecem dicas às desenvolvedoras sobre o código. Quando eles são muito complexos de ler e onde não há maneira de simplificá-los, você deve encarar isso como um code smell da sua aplicação.
Obviamente, o TDD desempenha um papel importante neste princípio, uma vez que TDD “visa eliminar o medo no desenvolvimento de software” — Kent Beck.
É fácil de Refatorar
- It is easy to Refactor
Frequentemente converso com as pessoas sobre testes, elas geralmente reclamam sobre como às vezes os testes tornam suas vidas miseráveis durante o processo de refatoração. Os testes não devem quebrar durante uma refatoração. Isso é um smell que seus testes não estão focando no ponto crucial de qualquer aplicação: seu comportamento.
Às vezes, desenvolvedoras se concentram muito nos detalhes de implementação. Quanto maior for o foco nos de detalhes de implementação dos seus testes, maior sera a dor da refatoração. Pegue leve com os mocks e certifique-se de validar o comportamento do aplicativo em vez da chamada de método.
É uma ferramenta de Debugging
- It is a DEBUGGING tool
Não há aplicações à prova de balas, bugs irão acontecer e, quando eles acontecerem, sua estratégia de teste deve ser capaz de simulá-los. Se você não consegue simular um bug, isso significa que existem alguns cenários que sua estratégia de teste não pode cobrir, e isso afeta diretamente o princípio “It Works”.
Certifique-se de que sua estratégia de teste evolua junto com a complexidade de seu aplicativo.
Com esses quatro princípios, a regra é reiterar! Discuta com sua equipe sobre a estratégia de testes de vocês. Verifique quais deles foram deixados de lado e como vocês podem evoluí-la. Espero que esses quatro princípios ajudem vocês a tomar decisões melhores e conscientes.
