Logo depois de ter conhecimento básico para programar, um desenvolvedor geralmente inicia um ciclo de melhorias em diversos pontos. Talvez você tenha optado por estudar arquitetura de software, alguns padrões de projeto, ou simplesmente tenha focado em algum framework ou linguagem. De todo modo, em algum momento surge a necessidade de entender o que são testes automatizados, como e por quê eles existem.

Nessa série de artigos vamos passear por alguns conceitos mais abstratos e trazer exemplos práticos sobre testes de software, além de ressaltar a importância em termos de negócios.

Antes de mais nada...

Quer ter uma experiência melhor? Esse repositório possui alguns links e uma base de código para o exemplo que será criado: uma API para encurtar links. Vale a pena conferir.

O que significa testar um software?

Existem diversas definições que geralmente são dadas em resposta a essa pergunta. No entanto, quem testa aplicações para "provar que elas funcionam", ou "mostrar que não existem erros", está com um viés limitante.

Testar é um processo de tentar "destruir a aplicação" ao máximo. De expor erros e evidenciar defeitos. Essa diferença no olhar é sutil, mas já trás benefícios. Caso os testes não mostrem locais em que o software precisa de melhorias, o valor agregado ao escrevê-los não é maior - na verdade é até menor, sem muito a acrescentar.

É interessante, também, saber diferenciar o que são falhas, erros e defeitos.

Quando um comportamento inesperado ocorre, existiu uma falha, que pode ter sido causada por diversos erros. O erro refere-se ao resultado de uma implementação incorreta. Essa inconsistência no software é um defeito.

Um exemplo pode ser uma tela de login que, mesmo quando usuário preenche todos os campos, exibe uma mensagem solicitando que o usuário informe alguns valores. Essa situação é uma falha, sendo que o defeito na validação desse formulário pode ter sido causado por uma função que retorna incorretamente se os dados foram devidamente preenchidos (poderia ser um operador ternário usado de forma invertida). Caso a funcionalidade não for afetada em um nível que o usuário consegue notar o comportamento estranho, ainda existem erro e defeito, mas não há falha.

Geralmente, defeitos são chamados de "bugs".

Por que escrever testes?

O primeiro ponto já foi comentado: testes agregam valor ao tornar mais simples a identificação de erros, reduzindo a quantidade de falhas. Mas existem outras motivações.

Uma das mais importantes é que um sistema com uma boa cobertura, por exemplo, é mais simples de ser mantido. Nesse caso, existe uma trava de segurança e é possível garantir que novas funcionalidades (ou refatorações) não danificam o que já estava funcionando. Também existe o fator documentação (amado pela comunidade de javascript): uma suíte de testes diz, exatamente, o que aquele programa precisa fazer. Em outra ótica, é uma lista de funcionalidades viva e que pode guiar um novo contribuidor sobre como utilizar aquele software.

Contudo, o real ganho se dá quando técnicas baseadas nesse processo, como TDD (Test Driven Development) ou BDD (Behavior Driven Development), são utilizadas. Os benefícios aqui vão desde ter um processo mais organizado e uma aplicação de princípios importantes (e.g separação de conceitos), até conseguir balancear qualidade e velocidade de entrega sem ficar preso em preciosismos ou gerar muitos débitos técnicos.

Imagine construir uma torre de dominós. A medida que mais peças são empilhadas, a dificuldade aumenta. Em um certo ponto, qualquer erro passa a ser suficiente pra que tudo caia e o trabalho seja perdido. Se você colocar um pouco de cola entre cada peça, toda a dor vai embora e o trabalho se torna fácil. As funcionalidades são como os dominós e a cola faz o papel de uma suíte de testes.

Pense sobre tudo isso. Olhe pra aplicações que talvez já tenha feito. Se você sente que elas são, de alguma forma, mais frágeis, é um bom início: imagine como a prática de escrever testes pode melhorar o seu trabalho!

Em breve vamos falar sobre TDD e BDD e começar a aplicar tudo isso num exemplo em Node. Até o próximo post!