Object Mother: cómo generar datos de test sin ensuciar tus tests

El patrón Object Mother como factoría de datos para tests: limpio, reutilizable y mantenible. Implementación real en Code Finances con Faker.

Después de un tiempo, volvemos con la serie de Code Finances. Esta vez vamos a algo clave pero muchas veces ignorado: cómo generar datos de test de forma limpia, reutilizable y mantenible.

"Para testear bien, primero necesitas datos válidos, coherentes y fáciles de generar."

Y aquí es donde entra en juego el patrón Object Mother.

🤔 ¿Qué es Object Mother?

El patrón Object Mother actúa como una factoría de datos para tests. Se encarga de crear objetos válidos — payloads, DTOs, requests — listos para usar, sin que tengas que construirlos manualmente en cada test.

⚠️ El problema sin Object Mother

Cuando no tienes una estrategia clara para generar datos de test:

• 🧩 Repites la creación de objetos en cada test
• 😵 Los tests se llenan de ruido (datos irrelevantes)
• 🔧 Cambiar un campo rompe múltiples tests
• 🧠 Pierdes el foco en lo importante: el comportamiento

🚀 La solución: centralizar la creación de datos

En lugar de construir los datos en cada test:

const request = new RequestRevenueCreator(
  'uuid',
  100,
  'SALARY',
  'description',
  '2024-01-01',
  'accountId',
  'userId'
)

Usamos un Object Mother:

const request = RevenueCreatorMother.createValidRequest()

Una sola línea. Datos válidos. Test limpio.

⚡️ Implementación en Code Finances

Creamos una clase encargada de generar datos válidos usando Faker:

export class RevenueCreatorMother {
  static createValidRequest(): RequestRevenueCreator {
    return new RequestRevenueCreator(
      faker.string.uuid(),
      faker.number.float({ min: 1, max: 10000 }),
      faker.helpers.arrayElement(Object.values(ERevenueIncomeSourceType)),
      faker.lorem.sentence(1),
      faker.date.past().toISOString().split('T')[0],
      faker.string.uuid(),
      faker.string.uuid()
    )
  }
}

Y en el test:

const request = RevenueCreatorMother.createValidRequest()

const result = await revenueCreator.execute(request)

💡 Faker: datos realistas sin esfuerzo

Faker nos permite generar UUIDs, valores de enums, fechas y textos. Esto evita datos hardcodeados, acerca los inputs a producción y genera variabilidad sin esfuerzo.

🧠 ¿Qué ganamos?

• ✅ Legibilidad — el test se enfoca en el comportamiento
• 🔁 Reutilización — un mismo generador sirve para muchos tests
• 🔧 Mantenibilidad — cambios centralizados
• 🔍 Separación de responsabilidades — los datos viven fuera del test

🧼 Buenas prácticas

• Mantén los Object Mothers simples
• Evita lógica compleja o decisiones internas
• Genera datos realistas, pero controlados
• Si necesitas variaciones, permite overrides sencillos

⚠️ Antipatrones a evitar

• 🚫 Usarlo como si fuera un Builder complejo lleno de métodos encadenados
• 🚫 Generar aleatoriedad sin control — los tests flaky son un infierno
• 🚫 Forzarlo cuando cada test necesita estructuras totalmente distintas

🧪 ¿Y si Object Mother no es suficiente?

Dependiendo del contexto, puedes combinarlo con otras alternativas o utilizar enfoques distintos:

• 🧱 Test Data Builders — más flexibilidad con métodos encadenados controlados
• 📁 Fixtures — útiles para datos persistidos en base de datos
• ⚙️ Factory Functions — rápidas pero menos estructuradas

💬 Conclusión

Object Mother no es solo una forma de generar datos. Es una forma de mantener tus tests limpios, legibles y sostenibles en el tiempo.

Porque un buen test no debería preocuparse por cómo crear datos… sino por qué comportamiento está validando.

Publicado originalmente en LinkedIn.