Skip to content

Evitando refatorações desnecessárias para seu código de teste.

No artigo de hoje eu falo sobre um dos piores pesadelos para quem faz testes de código: “refatoração desnecessária. Também irei mostrar como diminuir isso utilizando o padrão Builder.

Um dos maiores problemas para alguém que inicia teste de unidade é refatorar seu código por causa de uma mudança do código de produção. Por esse motivo, muitos chegam a dizer que os testes chegam mais a atrapalhar do que a ajudar.

Olhando o cenário acima eu digo que concordo totalmente com a pessoa que chega a dizer isso. Mas faço outra pergunta, qual é o verdadeiro problema? O trabalho para alterar o teste por motivo de mudança ou o código fraco que foi criado para seu teste? Vou responder, a segunda opção.

Um dos pilares do teste é que ele não seja acoplado ao código de produção. O que isso significa? Fazer com que qualquer alteração de produção não altere os testes. Nem sempre isso é possível mais devemos trabalhar para tentar ao máximo evitar esse problema.

No artigo de hoje vou apresentar um padrão que nos ajuda em muito a diminuir esse problema: Builder.

Para quem não conhece, Builder é um padrão de projeto utilizado para criação de objetos. Ele é parecido com o padrão Factory, porém cria-se um objeto de forma dinâmica.

Abaixo eu vou apresentar um teste fortemente acoplado com o código de produção e depois um código que não depende tanto assim do código de produção.

Vamos criar um domínio novo em nosso sistema e por isso vamos começar com os nossos testes. No código abaixo crio meu primeiro teste de unidade onde trata da criação do domínio e os demais métodos são testes de comportamentos.

Imagina o seguinte, você recebe um requisito onde deve alterar esse domínio e agora é possível informar se é um curso fechado. Falando de forma resumida vai ser somente uma propriedade nova em nosso domínio passando pelo construtor, certo?

E graças a esse novo requisito teremos que alterar todos os nossos testes de unidade que utilizam a criação desse domínio, new Curso(…). Em nosso exemplo temos somente alguns casos mais em um sistema real pode ser centenas. Você entendeu agora o meu ponto de vista quando falo que o problema não está na refatoração e sim na pobreza do código?

Criando nossa builder.

No código acima é possível ver a criação do nosso builder, com ele já inserimos valores default para a criação do domínio, mas também criamos métodos auxiliares para alterar os valores default, por exemplo “ComNome()”.

Criar um builder é extremamente fácil. Criamos um método estático para instanciar o nosso builder, “Novo()” e por último um método responsável por criar o domínio “Build()”. Com isso agora basta utilizar em nossos códigos de teste.

 

Viu como ficou fácil agora, qualquer alteração que tivermos em nosso domínio não irá mais causar tanto problema assim nos códigos de testes, pois agora em vez de alterar uma base de testes, vamos alterar apenas seu builder.

Alguém ainda deve estar reclamando, pow agora eu não altero mais a base de testes mas ainda tenho que criar builders para cada domínio, o trabalho não é o mesmo?

Vou te dar uma solução, que tal utilizar alguma biblioteca que faz isso?

Eu costumo utilizar a biblioteca NosBor.FluentBuilder para C# e você acha no Nuget e acredito que para outras linguagens também deva ter. Mas o que esse cara faz? Bom, tudo! Com ele você não precisa criar builders para cada domínio conforme o código abaixo.  Através dele eu informo qual classe quero criar e ainda setar suas propriedades, mesmo que seja uma private set.

E agora, qual a próxima desculpa?

Como podem ver, com a utilização de Builders nosso código começa a ficar mais estáveis as mudanças que podem ocorrer com o nosso código de produção e assim evitamos aquele tempo tendo que refatorar em todos os cantos utilizados.

Bom galera é isso e espero ter ajudado e até a próxima.

Você gostou desse artigo? Gostaria de saber mais sobre Testes? Eu desenvolvi um curso na Udemy, preço camarada. Acesse https://www.udemy.com/automatizando-testes-para-sua-aplicacao

Published inTestes

Be First to Comment

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *