Olá, visitante! Seja bem visto mais uma vez. Hoje iremos falar sobre Teste Unitário e o seu impacto em aplicações.

Vou usar como exemplo e parâmetro o Delphi e como ferramenta de Teste Unitário, o DUnitX.

Vi muitos artigos falando sobre Testes Unitários e a sua importância para o software, mas poucos falando de como aplicar e quais serão as garantias (não gosto muito de usar essa palavra) que isso gera para a aplicação e o time em si. Para isto, vou utilizar uma experiência profissional para gerar insumos para que possamos desenrolar esse "paradigma".

Recentemente realizei a implementação em uma das rotinas da empresa onde eu trabalho, de forma bem resumida, o papel dessa rotina é gerar devolução de venda. Com isto, vocês já imaginam quais dependências teremos com outras partes da aplicação, como: filial, cliente, venda, tributação, parâmetro, produto, estoque, etc.

Pois bem, com base na informação acima, já temos basicamente um "mapa mental" de quais as dependências existem nessa rotina em específico que já serve de norte para um monstro chamado REFATORAÇÃO.

Não vejo Teste Unitário sem refatoração, principalmente pelo fato de você precisar de que o seu software esteja muito bem organizado a nível de código, separado em classes, interfaces e seguindo um padrão de projeto (no meu caso eu optei pelo SOLID). O fato de eu ter optado por refatoração, não quer dizer que você também tem. Caso o seu software já esteja divido em camadas, é um trabalho a menos que você terá, mas sabemos que para grandes aplicações feitas em Delphi (principalmente os legados) isso é raro de se ver.

Após termos o mapa mental das dependências, vamos para o próximo monstro: REGRA DE NEGÓCIO. Esse, para mim, é o pior dos monstros. E regra de negócio normalmente é centraliza e/ou pouco compartilhada entre a equipe e neste ponto você tem duas alternativas: optar por transcrever o código legado para O.O. apenas no "olhômetro" ou ter um belo de um alinhamento com o seu P.O. ou analista de negócio para que descreva a regra do processo.

E aqui tem outro PONTO MUITO IMPORTANTE: se a rotina que você vai refatorar para implementar regra de negócio é simples, com processos básicos e poucos complexos (poucos mesmo), você pode tentar ousar (não faça isso sem antes fazer um brainstorming ou alinhamento com o time) refatorar tudo de uma vez. Agora, caso a rotina tenha uma complexidade maior, sem sombra de dúvidas opte por fazer uma lista (eu utilizei o TO-DO da própria IDE) do que vai ser refatorado, começando SEMPRE pelo tronco do processo. Por base na minha situação, eu comecei pelo objeto principal, o da DEVOLUÇÃO.

Vou explanar um pouco sobre por onde começar: sabendo que eu tenho um objeto base da devolução, pressupõe que também haja "sub-objetos" do objeto base, ou seja: objeto da filial, cliente, venda, tributação, etc. Para eu começar a fazer os meus testes unitários, tenho que ter isso tudo muito bem estruturado, pra mim é um dos pontos mais importantes, pois caso você gaste algumas horas e depois perceba que começou pelo lugar errado, vai ser um tempo perdido que você não vai conseguir ter novamente. Então tenha muito bem estruturado essa parte.

Por base no que disse acima, vamos criar um objeto de devolução com validações simples de regra de negócio, segue:


Repare que eu adicionei simplesmente uma propriedade do Código do Cliente para que seja preenchida. Repare também no nome do arquivo. Tente sempre utilizar padrões como este. Ajuda bastante e deixa tudo muito mais organizado. Até aqui, nada de complexidade.

Agora eu vou criar uma classe que vai ser a VALIDADORA (que é onde o nosso Teste Unitário trabalha) da classe de devolução, segue:


Essa é a minha classe de validar a devolução. Repare que a única dependências de uses que ela tem é da classe TDevolucao e da criação do Exception. Tente manter SEMPRE tudo muito desacoplado para que seja reutilizado e simples de ser usado.

Agora vamos usar a nossa imaginação de como ficaria o nosso software utilizando essas duas classes de forma bem sintética: Tenho a minha rotina de devolução e após selecionar a venda a ser devolvida, eu clico no botão GRAVAR, depois desse ponto entra no processo de preencher o nosso objeto TDevolucao (primeiro print) com os dados da devolução que até agora temos somente o código do cliente, e após preencher o objeto, irá chamar a classe TDevolucaoValidar para validar os dados preenchidos no passo anterior.


Vamos supor a partir de agora que a refatoração foi feita com sucesso, que passou pelo teste e que as regras de negócio estão todas certinhas. Partimos então para o Teste Unitário!

O primeiro passo é criar o projeto no Delphi, indo em: File > New > Other > DUnitX > DUnitX Project.

Ao clicar, irá abrir a tela a seguir e você vai deixar as opções marcadas conforme exibido:



Repare que eu coloquei o nome da classe do teste como a mesma da que eu vou validar, adicionado somente "Validar" no final.

E, após realizar a configuração acima, é assim que o seu projeto irá parecer:

Após o seu projeto configurado, vamos ao teste da nossa classe TDevolucaoValidar para verificar se o código do cliente é válido (ou não), segue o que fazer:

Primeiro, crie os dois métodos a seguir:

Os métodos acima são os dois casos de testes que irá ser feito. Eu separei em dois: o caso que vai dar certo e o que vai dar errado (a exceção) e irei explicar logo abaixo. Repare também que há dois parâmetros: um com a descrição do meu teste e outro com uma "array" de valores que serão passados por parâmetro pelo método abaixo. Ou seja, no meu método de sucesso, o parâmetro "Codigo" irá receber o valor 1 mesmo que isso não esteja explícito.

Agora repare como ficou a implementação:

Repare que eu preencho o meu objeto com o meu parâmetro e a seguir eu realizo teste de sucesso (ou não sucesso) do método. Eles são bem semelhantes e só muda uma função. Você está se questionando o motivo de não usar tudo na mesma função e a resposta é simples: eu vou ter que ter muitos IF's e isso não é algo que o Teste Unitário tem que ter. Deve ser claro e objetivo. Por isso optei trabalhar com a procedure que vai dar exceção e validá-la e com a que vai passar normalmente.

Após fazer isso, basta executar o seu projeto que terá o seguinte resultado em tela:



Pronto! Você testou a sua aplicação utilizando Teste Unitário e GARANTIU que o seu método seja validado corretamente com a informação estando correta ou não!

Obrigado!
Lucas de Souza Cruz