Construir datos de prueba con builders: valores por defecto válidos, desviaciones explícitas

Objetivo

Tests cuya preparación nombra únicamente los valores relevantes para la verificación y que, ante cambios en el modelo de datos, se ajustan en un solo lugar.

Requisitos previos

Entidades con reglas de validez claras (qué campos son obligatorios, qué combinaciones están permitidas); un lenguaje en el que se puedan expresar llamadas encadenadas o argumentos con nombre; un framework de pruebas que pueda construir los objetos sin base de datos o con una base de datos desechable.

Pasos

1. Crear un builder para cada entidad que aparezca en más de un puñado de tests: eine_bestellung() devuelve un pedido válido con valores por defecto razonables (un artículo, estado «abierto», cliente presente).
2. Definir un método de asignación con nombre por campo (.mit_status("bezahlt"), .mit_positionen(3)) o, en lenguajes con argumentos con nombre, una función con valores por defecto. El builder crea el objeto solo al llamar a .bauen().
3. En el test, establecer únicamente lo que afecta a la afirmación: un test sobre recordatorios de pago define el vencimiento y el estado, y nada más. Lo que no se menciona es irrelevante para el test; esa es la regla de lectura.
4. Evitar el azar o fijarlo: los valores por defecto son deterministas; donde se necesite unicidad (dirección de correo electrónico), usar un contador en lugar de valores aleatorios.
5. Construir los objetos relacionados con otros builders (.mit_kundin(eine_kundin().aus_land("CH"))) para que las relaciones sigan siendo válidas.
6. Ante un cambio en el modelo (nueva columna obligatoria, constructor modificado), ajustar primero el builder y después ejecutar los tests; solo se tocan los tests a los que el nuevo campo afecta en cuanto al contenido.
7. Conservar objetos «canónicos» compartidos (la clienta Meier, que aparece siempre) únicamente donde constituyan un vocabulario común con los expertos del dominio, y crear también estos mediante el builder.

Resultado esperado

Un test se lee como «dado un pedido con estado pagado y tres posiciones, cuando …, entonces …»; los cambios en el modelo provocan pocos ajustes de test, y locales; desaparecen los archivos de fixtures de cientos de líneas.

Límites y base de verificación

El patrón se distingue del Object Mother, que Martin Fowler describe como una fábrica de objetos de ejemplo conocidos y ya completos, y cuyo inconveniente señala como acoplamiento fuerte: muchos tests dependen de los datos exactos del Mother, lo que hace delicado modificarlo. Un builder por entidad exige mantenimiento y puede ocultar en qué valores por defecto se apoya un test de forma tácita. Si los builders reducen realmente el número de cambios en los tests está formulado en la wiki como una hipótesis propia, no como un hallazgo; no se afirma ninguna medición.