Ultimamente tenho dedicado parte do meu tempo a estudar com mais afinco assuntos relacionados à testes (em geral) e uma frase que com certeza ficou muito marcada na comunidade e propagada por um dos autores de conteúdo mais relevantes (na minha opinião) atualmente vai muito de encontro com algo que faz muito sentido quando você está escrevendo testes:

"Quanto mais seus testes assemelham-se à maneira que seu software é usado, mais confiança eles podem te oferecer"

Traduzido, originalmente escrito por Kent C. Dodds

E vai ser sobre essa forma de pensamento que pretendo comentar um pouco.

#Testando só por testar

Talvez você esteja em um ambiente profissional onde testes é uma "régua" de qualidade (atenha-se à essa palavra que já voltaremos a falar sobre ela em breve) para o código que você coloca em produção.

Não é difícil encontrar uma estrutura onde aplicações e repositórios possuem suas configurações para aceitar novos códigos (pull requests) com cobertura de testes (coverage) acima de uma determinada porcentagem. E é saudável manter um limíte viável para todo time se essa régua for de fato mantida e estiver claramente conciente para todo mundo.

Depois de algum tempo trabalhando com testes você começa a perceber alguns padrões responsáveis por gerar falsos-positivos (aqueles testes que passam, mas que não definem seguem um padrão de qualidade) e se você não estiver realmente atento é bem fácil de perceber futuramente que você acabou testando algum trecho de forma totalmente errônea ou que seu teste de fato não condiz com o que seu software realiza.

É muito fácil se perder quando seu foco é simplesmente atingir uma porcentagem de cobertura. Essa porcentagem deve ser levada em consideração para aumentar sua confiança e não como um valor a ser atingido desesperadamente, até porque, a gente sabe que no fim do dia não é tão difícil assim atingir uma meta de cobertura e é relativamente fácil se você sair por aí "mockando" (sobrescrevendo ações esperadas) qualquer módulo que seu sistema usa.

Às vezes você pode até pensar: "eu não faço código ruim, sei que meu código funciona como deveria". Mas inverter essa perspectiva e começar a pensar pelo pior cenário possível pode acabar dando mais confiança na entrega que você realiza.

#Confiança no seu código

Embora seja um pouco mais absurda, outra citação que sempre me lembro é a seguinte:

"Sempre desenvolva como se a pessoa que fosse manter seu código fosse um psicopata violento que sabe onde você mora"

Traduzido, fontes da internet indicam diversos autores, provavelmente feita por John Woods ou Martin Golding

E conseguimos tirar algo dela que vai de encontro com o tópico que estamos discutindo: a forma como você desenvolve tem um papel importante em algum usuário. Seja ele você futuramente quando for dar manutenção em algum sistema ou criar alguma funcionalidade nova, seja outra pessoa que manterá seu código após sua entrega ou seja o usuário final que utilizará o software que você desenvolveu.

Ninguém quer sofrer a penalidade de acordar com um alerta às 3 horas da manhã por algum trecho de código que não respondeu corretamente quando um tipo diferente de conta de usuário (que não estava coberta nos testes) acessou o sistema, assim como você não quer ser esse usuário penalizado que não consegue consumir a informação que precisa.

Métricas devem existir e devem ser um instrumento de apoio à confiança que você têm no seu código e dessa forma você consegue entregar qualidade para um usuário (de qualquer tipo) e ter a garantia de que seu software está agindo como deveria, e é com base nessa confiança que você deve garantir seus testes estão de acordo como a forma que seu software é utilizado.