Los test data builders con valores por defecto reducen las roturas de tests cuando cambia un objeto de dominio

Hipótesis

Un object mother, según la descripción de Fowler, es una factory que devuelve objetos predefinidos y conocidos ("John, contratado la semana pasada") compartidos por muchos tests. Como defecto señala el fuerte acoplamiento que surge porque muchos tests dependen de los datos exactos del mother, lo que complica cambiar esos datos. Un test data builder adopta el enfoque contrario: parte de un objeto por defecto válido y expone un método por campo, de modo que an_order().with_status("paid").with_lines(3).build() indica exactamente los campos de los que depende el test y hereda todo lo demás. La hipótesis es la siguiente: cuando se añade un campo obligatorio a un objeto de dominio, cambia la firma de un constructor o se endurece una regla de validación, las suites basadas en builders necesitan ediciones en un solo lugar (los valores por defecto del builder), mientras que las suites que construyen los objetos directamente, cargan fixtures compartidos o dependen de instancias predefinidas de un mother necesitan ediciones proporcionales al número de tests que usan el objeto. Una afirmación secundaria se refiere a la legibilidad: los campos que aparecen en un test al estilo builder son justamente aquellos de los que depende la aserción, por lo que quien lee no necesita comparar el test con un archivo de fixtures.

Predicción

En el historial de versiones, los commits que añaden un campo obligatorio a una entidad o modifican su constructor afectan a menos archivos de test, normalizados por el número de tests que usan la entidad, en las bases de código donde la entidad se construye mediante un builder que en las que usan construcción directa, archivos de fixtures o un object mother. Cuando se pregunta a revisores "¿de qué campos depende este test?", responden con más rapidez y precisión en el caso de los tests al estilo builder.

Prueba propuesta

1. Seleccionar repositorios en los que convivan ambos estilos, o una misma base de código antes y después de introducir builders para un conjunto de entidades.
2. Identificar los commits que añaden un campo obligatorio o cambian un constructor; contar los archivos de test modificados y las líneas de test modificadas por commit, agrupados por estilo de construcción, y normalizar según el número de usos.
3. Para la afirmación sobre legibilidad, dar a los revisores pares de tests equivalentes (mismo comportamiento, ambos estilos) y medir el tiempo que tardan en identificar los campos de los que depende la aserción.

Estado

No se afirma ningún resultado. Los builders cuestan una clase por entidad y pueden ocultar qué valores por defecto usa un test sin que se note; los object mothers conservan su utilidad para ejemplos compartidos y con nombre que aparecen en las conversaciones con los usuarios. La hipótesis se refiere al número de ediciones ante un cambio y a la legibilidad, no a la detección de defectos.