É importante ressaltar que esse artigo não trata sobre testes de aceitação realizados por usuários com o auxílio de um designer ou inspetor, mas sim sobre testes que são escritos ou criados para serem executados de forma autônoma, como vocês verão nos próximos capítulos.

O que são testes de software?

Esse tópico tem o objetivo de demonstrar, através da teoria e prática, o que são testes de software e sua importância dentro de uma aplicação. Então, caso você ainda não tenha esse conhecimento, sugiro que não pule essa parte do artigo.

Testes de software basicamente são trechos de código escritos por uma equipe de testes - ou em muitos casos pelas pessoas desenvolvedoras - cujo intuito é validar, de forma autônoma, se software (ou parte dele), está se comportando da forma esperada. Para tal, é aplicado um método do científico, onde você parte de hipóteses e experimentações com o objetivo de chegar a uma conclusão, que normalmente está relacionada ao questionamento "essa aplicação se comporta de maneira esperada?".

Para exemplificar, pegue o exemplo em pseudo código abaixo:

func soma(a, b):
    return a + b;

// Testando a função soma
soma(1, 2) deve ser igual a 3
soma(4, 7) deve ser igual a 11

O exemplo anterior pode ser quebrado dos passos a seguir:

1. Criamos uma função soma que faz alguma coisa;
2. Refletimos sobre qual o comportamento esperado da função e chegamos a conclusão que, ao receber dois números como parâmetros, ela deveria nos retornar a soma de ambos;
3. Baseado na reflexão anterior, definimos algumas hipóteses:
   1. Ao chamar a função soma com os números 1 e 2, eu espero que ela me retorne o número 3;
   2. Ao chamar a função soma com os números 4 e 7, eu espero que ela me retorne o número 11;
4. Agora chegou a hora da experimentação, que é feita através da execução de nossos testes;
5. Ao executar os testes, caso a função soma esteja de acordo com as nossas hipóteses, os testes vão rodar sem mensagens de erro;
6. Agora chegamos a etapa de conclusão, onde nós avaliamos o resultado do passo anterior e fazemos a seguinte reflexão: "O comportamento do código testado está suficientemente satisfatório? Tendo em vista a experimentação de nossas hipóteses ". Caso a resposta seja afirmativa, podemos dizer que a nossa função está de acordo com o comportamento esperado, além de estar coberta pelos testes.

Dessa forma, nós podemos dizer que os testes de software servem como um método científico usado para garantirmos a assertividade comportamental de nosso código, servindo também como um registro histórico que evita a inserção de problemas em recursos já existentes na aplicação. Visto que, uma vez que os todos comportamentos desenvolvidos estejam cobertos por testes, linhas de código problemáticas farão com que hipóteses antigas passem a ser tomadas como inválidas, fazendo com que, uma vez que os testes sejam executados, mensagens de erro sejam informadas a pessoa desenvolvedora.

Porque testar?

Para explicar os benefícios de se ter uma aplicação coberta por testes, gostaria de apresentar alguns pontos que são perceptíveis tanto a curto quanto a médio e longo prazo.

Curto Prazo

No início, as pessoas tendem a não compreender muito bem por que estão "gastando" tempo escrevendo testes em vez de criar novos recursos. Porém começam a perceber, aos poucos, que os testes estão evitando que problemas "simples" sejam publicados em produção, o que acaba aumentando a produtividade e confiança da equipe, já que não é mais necessário ficar "apagando fogo em produção" toda hora.

Paralelo a isso, as pessoas começam a entender e desenvolver a aplicação como um conjunto de componentes que "fazem uma única coisa", já que assim você contrói elementos que podem ser testados isoladamente. Também é aqui onde o time começa a ver a importância prática de bons princípios no desenvolvimento como o SOLID).

Outro ponto muito perceptível é que os testes passam a servir como documentação durante a "code review", já que eles mostram, de forma prática, qual o comportamento esperado dos recursos em desenvolvimento.

Médio e Longo Prazo

Aqui nós vemos um movimento onde o foco do time passa a ser majoritariamente em desenvolver novos recursos, pois o sistema está coberto por testes e isso significa que serão raras as vezes onde problemas em produção ocorrerão, e, quando ocorrerem, um novo teste será criado cobrindo os comportamentos inesperados. Dessa forma, caso alguém cometa o mesmo erro no futuro, os testes existentes servirão para indicar um possível problema em tempo de desenvolvimento.

Além disso, o time começa a usar os testes antigos como documentação, permitindo assim o entendimento de como o software foi projetado e pensado, ajudando na manutenção do sistema e prevenindo a quebra acidental de regras de negócio previamente estipuladas.

Outro evento que pode ser percebido nesse momento está relacionado à satisfação das partes envolvidas (stakeholders) quanto ao time de desenvolvimento, pois menos problemas em produção significa que menos clientes estão ligando para o suporte insatisfeitos com a empresa.

Regra 10 de Meyers

Além dos pontos previamente mencionados, gostaria de compartilhar a Regra 10 de Meyers, que foi desenvolvida pelo cientista da computação chamado Glenford Myers e, resumidamente, estipula que "quanto mais esperamos para resolver um problema no ciclo de vida da aplicação, maior será o custo da resolução desse problema". Isso quer dizer que o custo de correção está diretamente relacionado ao tempo de descoberta do problema, de tal forma que problemas descobertos ainda em de desenvolvimento são muito mais baratos de serem resolvidos do que quando são percebidos e reportados por um cliente. Já que, para corrigir um problema em produção, seria necessário encontrar a versão com problema, avisar os clientes afetados, marcar o deploy da nova versão, e esse ciclo segue até que sejam gasto dias para resolver um problema que poderia ser facilmente identificado através de um teste antigo.

Se ainda não acredita em mim, veja a seguir um gráfico que representa o custo de correção de um problema vs o tempo levado para identificá-lo.

Conclusão

Muitas vezes as pessoas começam a desenvolver aplicações sem testes de software pelos mais variados motivos, que podem vir desde a tempo de vida do projeto, pressão das partes interessadas, ou até pela falsa sensação de produtividade, porém esse débito técnico acaba tornando o desenvolvimento insustentável a longo prazo, já que que qualquer alteração no software resulta em problemas reportados e clientes insatisfeitos, fazendo assim com que as pessoas desenvolvedoras passem a tomar meses no desenvolvimento de recursos que no início do projeto poderiam ser feito em semanas (simplesmente por "medo de quebrar algo no código"). Como uma medida desesperada, a empresa tenta contornar a baixa de produtividade adicionando cada vez mais pessoas na equipe, o que só acaba amplificando o problema, pois agora o time também terá que lidar com pessoas inexperientes com o software, que vão criar bugs simplesmente pela falta de conhecimento sobre os alinhamentos e regras de negócio do sistema.

Tendo esse cenário em vista, finalizo com a seguinte frase:

"Por que a maioria dos desenvolvedores teme fazer mudanças contínuas em seu código? Eles tem medo de quebrá-lo! Por que eles têm medo de quebrá-lo? Porque eles não têm testes" - Robert C. Martin