Test data builders com valores padrão reduzem a quebra de testes quando um objeto de domínio muda

Hipótese

Um object mother, na descrição de Fowler, é uma fábrica que devolve objetos conhecidos e prontos ("John, hired last week") compartilhados por muitos testes. Ele aponta como defeito o forte acoplamento que surge porque muitos testes dependem dos dados exatos do mother, o que torna delicada qualquer alteração nesses dados. Um test data builder adota a postura oposta: parte de um objeto padrão válido e expõe um método por campo, de modo que an_order().with_status("paid").with_lines(3).build() declara exatamente os campos dos quais o teste depende e herda todo o resto. A hipótese é a seguinte: quando um campo obrigatório é adicionado a um objeto de domínio, a assinatura de um construtor muda ou uma regra de validação fica mais restritiva, as suítes baseadas em builders precisam de edições em um único lugar (os valores padrão do builder), enquanto as suítes que constroem objetos diretamente, carregam fixtures compartilhadas ou dependem de instâncias prontas de um mother precisam de edições proporcionais ao número de testes que usam o objeto. Uma afirmação secundária diz respeito à legibilidade: os campos nomeados em um teste no estilo builder são precisamente aqueles dos quais a asserção depende, de modo que o leitor não precisa comparar o teste com um arquivo de fixtures.

Previsão

No histórico de versões, os commits que adicionam um campo obrigatório a uma entidade ou alteram seu construtor tocam menos arquivos de teste, normalizados pelo número de testes que usam a entidade, em bases de código nas quais a entidade é construída por meio de um builder do que naquelas que usam construção direta, arquivos de fixtures ou um object mother. Revisores a quem se pergunta "de quais campos este teste depende?" respondem com mais rapidez e precisão no caso de testes no estilo builder.

Teste proposto

1. Selecionar repositórios em que os dois estilos coexistem, ou uma única base de código antes e depois da introdução de builders para um conjunto de entidades.
2. Identificar os commits que adicionam um campo obrigatório ou alteram um construtor; contar os arquivos de teste alterados e as linhas de teste alteradas por commit, agrupando por estilo de construção e normalizando pela contagem de usos.
3. Para a afirmação sobre legibilidade, dar aos revisores pares equivalentes de testes (mesmo comportamento, nos dois estilos) e medir o tempo que levam para identificar os campos dos quais a asserção depende.

Estado

Nenhum resultado é afirmado. Builders custam uma classe por entidade e podem esconder quais valores padrão um teste usa sem que isso fique explícito; os object mothers mantêm seu valor para exemplos nomeados e compartilhados que aparecem nas conversas com os usuários. A hipótese trata do número de edições em caso de mudança e da legibilidade, não da detecção de defeitos.