Montar dados de teste com builders: padrões válidos, desvios explícitos

Objetivo

Testes cuja montagem menciona apenas os valores relevantes para a verificação e que, quando o modelo de dados muda, precisam de ajuste em um único lugar.

Pré-requisitos

Entidades com regras de validade claras (quais campos são obrigatórios, quais combinações são permitidas); uma linguagem em que se possam expressar chamadas encadeadas ou argumentos nomeados; um framework de testes capaz de montar os objetos sem banco de dados ou com um banco descartável.

Passos

1. Para cada entidade que aparece em mais do que um punhado de testes, criar um builder: eine_bestellung() devolve um pedido válido com padrões sensatos (um item, status «aberto», cliente presente).
2. Para cada campo, um método setter nomeado (.mit_status("bezahlt"), .mit_positionen(3)) ou, em linguagens com argumentos nomeados, uma função com valores padrão. O builder só cria o objeto em .bauen().
3. No teste, definir apenas o que diz respeito à asserção: um teste sobre cobranças de pagamento em atraso define o vencimento e o status, e nada mais. O que não é mencionado é irrelevante para o teste – essa é a regra de leitura.
4. Evitar aleatoriedade ou fixá-la: os padrões são determinísticos; onde for preciso unicidade (endereço de e-mail), usar um contador em vez de valores aleatórios.
5. Montar objetos relacionados por meio de outros builders (.mit_kundin(eine_kundin().aus_land("CH"))), para que os relacionamentos continuem válidos.
6. Quando o modelo muda (nova coluna obrigatória, construtor alterado), primeiro ajustar o builder e depois executar os testes; só se mexe nos testes que tratam do novo campo em termos de conteúdo.
7. Manter objetos «canônicos» compartilhados (a cliente Meier, que aparece sempre) apenas onde servem de vocabulário comum com especialistas de negócio – e mesmo esses devem ser criados por meio do builder.

Resultado esperado

Um teste lê-se como «dado um pedido com status pago e três itens, quando …, então …»; mudanças no modelo geram poucos ajustes de teste, e locais; desaparecem os arquivos de fixtures com centenas de linhas.

Limites e base de verificação

O padrão distingue-se do Object Mother, que Martin Fowler descreve como uma fábrica de objetos de exemplo conhecidos e já prontos, e cuja desvantagem ele identifica como acoplamento forte: muitos testes dependem dos dados exatos do Mother, o que torna delicada qualquer alteração dele. Um builder por entidade tem custo de manutenção e pode esconder em quais padrões um teste se apoia silenciosamente. Se os builders realmente reduzem o número de alterações em testes está formulado no wiki como hipótese própria, não como constatação; não se afirma nenhuma medição.