Boas vindas novamente pra você que está nessa jornada interior para decifrar o segredo da felicidade, o significado da vida e de todos os 1387 termos relacionados a OOP. Veja os artigos anteriores aqui e aqui.

Hoje o fabuloso Dalai Lama vai doar um pequeno farelo do grande biscoito de Dharma que ele cozinhou ao logo da vida para vocês e falar sobre os aspectos mais importantes sobre Testes Unitários (Unit Testing) e por que você deveria lamentar com lágrimas cada linha de código escrita sem eles.

Como você nem deve imaginar, a maioria do tempo de um programador ele passa não-programando. Não que ele seja vagabundo, porque ele não é um ex-bbb, mas existem uma série de microtarefas de suporte que um programador precisa fazer. E entre coisas como documentar, configurar ambientes e resolver dependências a mais chata de todas as tarefas é testar.

dalai lama

O jeito mais arcaico de testar as coisas é modificar o código pra exibir várias mensagens de depuração na execução e rodar o programa, então repetir como um servo egípcio até que você encontre o problema. Se o bug está na tela 22 que requer que você passe pelas 21 anteriores, você tem que ir pacientemente por cada uma delas.

Para não repetir várias vezes essa coisa chata, criaram os depuradores linha-a-linha para congelar a execução do programa e ir avançando linha por linha, enquanto vê os valores de cada variável e retornos dos métodos. Assim você não precisa nem modificar o código para exibir as mensagens de depuração. Programadores VB6 e Delphi passam 104% das suas vidas nessa vibe doida.

Os testes unitários não tem nada dessa merda. O conceito é simples: Ao invés de escrever apenas o código principal do software, você escreve e mantém duas bases de código:

1. O software em si.
2. Um outro software, que testa o primeiro automaticamente.

Isso mesmo, você ouviu direito. Você vai programar mais, mas aí que vem a parte boa: Sem testes manuais. Você roda o software número 2 e em poucos segundos ele diz se o software número 1 funciona ou não, e exibe um resumo de quais métodos funcionaram e quais falharam. Coisa fina regada com mel.

duas: melhor que uma

Testes Unitários: O Porquê do nome

Uma unidade, ou unit, é a menor parte testável de um software. Lembra que em OOP tudo é organizado em classes de objetos que tem um conjunto específico de métodos (operações)? Geralmente, cada método é uma unidade e cada método é testado separadamente.

Se tudo é organizado em objetos que possuem métodos, basta escrever testes para todos os métodos que teoricamente todo o sistema estará testado. Geralmente só é possível testar uns 90% de todos os métodos, seja pela praticidade ou por dependências entre eles. Mas isso normalmente é muito muito mais do que você testaria manualmente.

Dois petiscos com uma mordida só

Documentar é provavelmente a segunda coisa mais chata depois de testar manualmente software. Os testes unitários também ajudam nesse aspecto.

Testar um método significa usá-lo. Na maioria dos casos, o código dos testes unitários é uma excelente biblioteca de exemplos de como utilizar os métodos do software principal. Isso entra em sinergia com o princípio da reusabilidade na OOP: software testado e cheio de exemplos de como reutilizar!

Conclusão

Use testes unitários. Fim.

Alexandre Gaigalas

Desenvolvedor PHP há tanto tempo que nem lembra direito há quanto tempo é desenvolvedor, o que talvez seja Alzheimer precoce.

Website - Twitter - Facebook - More Posts