Neste post, vamos explorar algumas boas práticas na escrita de Test Data Builders. Mas para entender o que são "bons" builders, primeiro precisamos entender o que são builders "ruins".

"Bom" e "ruim" são distinções claramente subjetivas, e os exemplos que listei abaixo são baseados na minha experiência pessoal e refletem a minha opinião apenas.

#Erros comuns e Antipatterns

Builders ajudam bastante, mas temos que tomar alguns cuidados. Vamos ver alguns antipatterns comuns que já observei muitas pessoas fazendo (inclusive eu).

#Tentar prever o futuro

Um erro comum que muitos desenvolvedores cometem ao implementar novo builder para testes é tentar prever o futuro. Eles fazem isso criando métodos para configurar cada propriedade do objeto em questão, mesmo quando no momento, só precisam customizar uma ou duas propriedades, como no exemplo abaixo: com um monte de código basicamente inútil, e que pode não ser nem útil quando essas propriedades vierem a ser customizadas.

Nessas horas é bom nos lembrarmos do princípio YAGNI, ou You aren't gonna need it! (Você não vai precisar disso!), que tende a ser bastante verdadeiro. Desenvolvedores, como qualque outro ser humano, são péssimos em adivinhar o futuro. A recomendação aqui é simples: implemente customizações apenas para o que for necessário.

#Inicializar os valores padrão direto nos fields

Outro erro muito fácil de cometer e ser tentado a jogar os valores padrão direto nos fields, como é feito na imagem abaixo.

Uma primeira desvantagem desta abordagem é que ela não prioriza explicitamente os valores customizados. Ao invés disso, dá maior importância aos valores padrão.

Vejamos agora o mesmo builder, só que com as inicializações no construtor:

À primeira vista pode parecer que estamos fazendo exatamente a mesma coisa: se não customizarmos uma propriedade, ela vai usar o valor padrão.

Mas deixar para tomar esta decisão na etapa de construção tem algumas vantagens. Em primeiro lugar, tudo o que envolve a definição de uma propriedade fica condensado num pequeno trecho de código como este:

Temos ali a propriedade e a seleção do valor final. Note que neste caso, o valor customizado vem primeiro. Estamos literalmente dizendo que será o valor customizado de _logradouro, e caso contrário o valor padrão "Rua 7 de Setembro".

Ou seja, ao selecionar o valor das propriedades nesta etapa, deixamos explícita a prioridade dos valores customizados sobre os valores-padrão. E explícito é quase sempre melhor que implícito.

Existe outra vantagem em implementar dessa forma: é mais fácil implementar cenários propositalmente inválidos. Isso pode soar estranho, mas vejamos um exemplo.

Neste caso, a seleção do valor para a propriedade Operacao do pedido deixa de ser binária com a introdução da possibilidade de ela não ter valor. Basicamente, estamos escolhendo ignorar o valor padrão.

A lição aqui é que, sempre que possível, devemos adiar a seleção do valor de uma propriedade. Assim conseguimos manter toda essa lógica condensada, e o código vai tender a continuar simples.