El problema real en entornos enterprise

En sistemas legacy ocurre algo recurrente:

El software funciona.
Pero nadie quiere tocarlo.

No porque esté bien diseñado, sino porque su comportamiento está distribuido, implícito y parcialmente desconocido. Cualquier cambio puede romper algo que nadie sabe exactamente cómo funciona, pero que el negocio da por sentado.

En este contexto, el Golden Master Pattern no es una técnica “de testing más”.
Es una herramienta de caracterización de comportamiento

¿Qué es el Golden Master Pattern?

El Golden Master Pattern (también conocido como Approval Testing) es una técnica de testing orientada a:

Capturar el comportamiento observable actual de un sistema y garantizar que no cambia involuntariamente con el tiempo.

Es importante entender esto:

Golden Master no valida que el sistema haga lo correcto.
Valida que el sistema siga haciendo lo mismo.

Eso lo convierte en una herramienta ideal para:

  • Refactorizaciones profundas

  • Migraciones tecnológicas

  • Modernización de código legacy

  • Reescrituras internas manteniendo contratos externos

Characterization vs Specification

Conviene diferenciar dos tipos de tests:

Specification Tests

  • Verifican intención.

  • Validan reglas de negocio.

  • Confirman que el sistema cumple requisitos.

Characterization Tests (Golden Master)

  • Capturan comportamiento actual.

  • No interpretan intención.

  • Actúan como red de seguridad frente a cambios.

Golden Master pertenece a la segunda categoría.

El problema clásico en .NET

Imaginemos un método sencillo:

public static class CsvGenerator
{
    public static string Create(params string[] names)
    {
        return string.Join("\n",
            names.Select(s => $"{s},{s.Length}"));
    }
}

Test tradicional:

[Test]
public void TestWithAssertions()
{
    var actual = CsvGenerator.Create("izzy", "sienna", "gabriel");
    var lines = actual.Split('\n');

    Assert.AreEqual("izzy,4", lines[0]);
    Assert.AreEqual("sienna,6", lines[1]);
    Assert.AreEqual("gabriel,7", lines[2]);
}

Funciona.
Pero es frágil.

Si el formato cambia ligeramente, debes modificar múltiples asserts.
Si el output es grande (JSON complejo, XML, reportes financieros), el test se vuelve ilegible.

Golden Master en acción

En lugar de validar partes, validamos el resultado completo.

Archivo expected.txt:

izzy,4
sienna,6
gabriel,7

Test Golden Master:

[Test]
public void GoldenMasterTest()
{
    var actual = CsvGenerator.Create("izzy", "sienna", "gabriel");
    var expected = File.ReadAllText("expected.txt");

    Assert.AreEqual(expected, actual);
}

Un ejemplo más realista

Imaginemos un motor que:

  • Recibe datos legacy

  • Los transforma

  • Genera un JSON complejo consumido por otro sistema

Ese JSON puede tener:

  • Cálculos internos

  • Campos opcionales

  • Orden específico

  • Lógica acumulada durante años

Descomponer todo en asserts individuales es inviable.

En ese escenario:

  1. Ejecutas el sistema actual.

  2. Capturas el JSON resultante.

  3. Lo conviertes en Golden Master.

  4. Refactorizas o migras.

  5. Comparas resultados.

Si coinciden → comportamiento preservado.
Si no → regresión detectada.

¿Cuándo tiene sentido usarlo?

Golden Master es especialmente potente en:

  • Modernización de legacy.

  • Migraciones VB6 → .NET.

  • Generadores de informes.

  • Transformaciones masivas de datos.

  • Sistemas con lógica compleja difícil de descomponer.

En procesos de refactorización profunda, la pregunta clave no es:

“¿Está perfectamente diseñado?”

Sino:

“¿He cambiado el comportamiento sin querer?”

Golden Master responde exactamente a eso.

ApprovalTests en .NET

En el ecosistema .NET existe la librería: ApprovalTests.Net, que permite automatizar el patrón.

[Test]
public void GoldenMasterApprovalTest()
{
    var result = CsvGenerator.Create("izzy", "sienna", "gabriel");
    Approvals.Verify(result);
}

Flujo:

  • Primera ejecución → genera .received.txt

  • Se revisa manualmente

  • Se aprueba como .approved.txt

  • En ejecuciones futuras compara automáticamente

Ventajas:

  • Gestión automática de archivos

  • Integración con herramientas de diff

  • Flujo profesional para equipos

Riesgos y errores comunes

Golden Master no es una solución mágica. Tiene implicaciones que debes entender.

Puedes congelar bugs

Si capturas un comportamiento incorrecto como Golden Master, estarás protegiendo un error.

Por eso es recomendable:

  • Revisar cuidadosamente el primer resultado

  • Validar con negocio antes de aprobarlo

No determinismo

Si el output contiene:

  • Fechas

  • GUIDs

  • Timestamps

  • Orden no estable

Debes normalizarlo antes de compararlo.

No sustituye tests semánticos

Golden Master no reemplaza:

  • Tests de reglas de negocio

  • Tests de dominio

  • Tests de contrato

Es una red de seguridad estructural, no semántica.

Comparación

Testing Tradicional Golden Master
Verifica intención Verifica estabilidad
Granular Global
Ideal para código nuevo Ideal para legacy
Detecta errores lógicos Detecta cambios estructurales

Aplicación en modernización legacy

En una migración VB6 → .NET, por ejemplo:

  1. Ejecutas el sistema VB6.

  2. Capturas outputs críticos.

  3. Generas Golden Masters.

  4. Implementas la versión en .NET.

  5. Ejecutas comparaciones automáticas.

Esto permite:

  • Refactorizaciones agresivas.

  • Reestructuración interna completa.

  • Migraciones progresivas.

  • Reducción de riesgo técnico.

Golden Master se convierte en un contrato implícito entre pasado y futuro.

Conclusión

El Golden Master Pattern no mejora tu diseño.
No limpia tu arquitectura.
No sustituye buenas prácticas.

Pero en sistemas críticos te da algo esencial:

Confianza para cambiar sin romper.

Y en modernización, la confianza no es un detalle técnico.
Es el habilitador estratégico de cualquier transformación.