Crear un framework de automatización de pruebas: las partes que nadie presupuesta

Qué contiene realmente un framework de automatización de pruebas

A eso se suman informes que la gente lea de verdad, la configuración de entornos, la política de reintentos y una forma de poner en cuarentena una prueba inestable sin perderla. Las pruebas en sí suelen ser la parte más pequeña.

El costo oculto

Cada una de esas piezas la construye quien montó el framework, con un estilo que solo esa persona entiende del todo. Cuando se va, el framework se convierte en algo que el equipo teme tocar, y una suite que da miedo cambiar es una suite que se pone en cuarentena en vez de repararse.

Cuándo tiene sentido construirlo

• Requisitos poco habituales. Un protocolo, una plataforma o una restricción de cumplimiento que ninguna solución lista para usar resuelve.

• Las pruebas son el núcleo del producto. Si vendes fiabilidad, ser dueño del arnés de pruebas puede ser estratégico.

• Tienes capacidad sostenida. No una persona durante un trimestre. Un responsable durante años.

Cuándo no lo tiene

Si el motivo real es que al equipo le gusta construir herramientas, o que una evaluación no resultó concluyente, el framework se construirá y luego se abandonará poco a poco. Ese es el caso común y conviene decirlo antes del primer commit.

Señales de que el framework se convirtió en el producto

Conviene tener algunas señales concretas, porque la transición es gradual y nadie la anuncia.

Alguien pregunta cómo añadir una prueba y explicarlo lleva más de dos minutos. Las personas nuevas del equipo escriben su primera prueba copiando una existente y cambiando valores, sin entender los fixtures que hay debajo. Ante una prueba fallida, la pregunta que surge es si cambió el framework. Hay un archivo que nadie quiere tocar. El trabajo sobre el framework aparece en la planificación del sprint como un ítem propio, de forma habitual.

Con dos de esas señales ya tienes un producto cuya base de clientes internos es un solo equipo. Eso no está mal por definición; muchas organizaciones lo han elegido de forma deliberada. Solo es un problema cuando ocurrió sin que nadie lo decidiera, que es lo habitual.

El punto intermedio

Conserva las pruebas escritas a mano para los casos que especificaste de forma deliberada, y deja que la cobertura generada se encargue de la amplitud, con los problemas de sesión, datos, orden y limpieza resueltos como parte del producto y no como infraestructura tuya.

La misma configuración está disponible en el panel de TestSprite si prefieres no instalar nada en local. El resto de la superficie del CLI está en el repositorio del CLI.

Si el pipeline pertenece a otro equipo, la GitHub App es el camino de menor resistencia: es un webhook, no cambia nada en tu repositorio y se dispara cuando tu build informa que la nueva versión está en producción. Si prefieres que la verificación se vea en el repositorio, un paso de GitHub Actions lo hace.

Lo que obtienes en lugar de construirlo

Las partes que iban a ser tu infraestructura vienen como producto. Auto-Authentication mantiene vivas las sesiones durante toda una ejecución, Dynamic Variables traslada valores entre llamadas, Dependency Chains deduce el orden de ejecución y Auto-Cleanup elimina exactamente lo que creó la ejecución. Los informes, la configuración de entornos y el comportamiento de reintentos vienen con ellas, así que nada de eso termina siendo un archivo que nadie quiere tocar.

La cobertura se genera a partir de tu producto y se refina en lenguaje sencillo, lo que elimina la otra mitad del costo: la parte en la que cada prueba tiene que escribirla alguien cuyo tiempo está en disputa.

El punto no es que construir esté mal. Es que la mayoría de los equipos nunca decidieron construir y descubren en el noveno mes que tienen un producto con un único cliente interno. Conservar las pruebas que especificaste de forma deliberada y dejar que el arnés de pruebas sea problema de otro es la versión de esto que no acumula un responsable que nunca presupuestaste.