Anatomía de un harness: las 6 piezas que toda herramienta comparte

En la parada anterior le pusimos nombre a la cosa que te paraliza: cuando te dicen “arma un framework desde cero”, te piden un harness. Y te mostré sus piezas a vuelo de pájaro — cuatro funciones que algo tiene que cumplir para que un test corra.

Te mostré cuatro a propósito, porque desde el avión son las que se ven. Cuando bajas a caminar el terreno aparecen seis: dos venían escondidas dentro de las otras. Hoy las separamos y les ponemos nombre.

Esta es la anatomía completa. Con ella vas a poder abrir cualquier framework —Playwright, k6, Appium, el que sea— y señalar cada pieza con el dedo. No para memorizar una herramienta, sino para reconocer el esqueleto que todas comparten.

Y no la leas como teoría suelta: este mapa es lo que abre los dos caminos donde la serie se pone práctica —construir tu framework de verdad, herramienta por herramienta, y ponerle el mismo arnés a tu agente de IA—. Hoy dibujamos el mapa; sin él, esos dos caminos son andar a ciegas. De paso te vas con una checklist para radiografiar cualquier framework, el tuyo o el que heredaste, en una tarde.

De cuatro a seis: qué faltaba

Recordemos las cuatro que ya viste:

• Algo que prepara el estado — tus fixtures.
• Algo que dispara los casos — el runner.
• Algo que define “correcto” — el oráculo, tus assertions.
• Algo que te cuenta qué pasó — el reporting.

Ninguna sobra. Lo que pasa es que dos de ellas juntaban dos trabajos distintos bajo una sola etiqueta, y desde el avión ese detalle se perdía.

La primera se esconde dentro del runner. Cuando dije “algo que dispara los casos”, junté en una sola palabra dos trabajos distintos: el que organiza y lanza los casos, y el que efectivamente toca el sistema bajo prueba. Un browser no es lo mismo que el programa que decide en qué orden corren tus tests. Son dos funciones, y las voy a llamar runner y herramientas. Vale la pena separarlas desde el principio: en algunas herramientas llegan a correr como procesos distintos, y en un momento lo vas a ver en Appium.

La segunda no estaba en las cuatro porque un test suelto no la necesita. Es la CI / orquestación: quién corre todo esto, cuándo, y con qué frecuencia. Un test que corres en tu máquina no la usa. Un framework que tiene que sobrevivir —correr solo, en cada push, sin que nadie se acuerde de apretar el botón— no existe sin ella.

Cuatro que ya conocías, más estas dos. Seis piezas.

Las seis piezas, en tres herramientas

Acá está el corazón de la parada. La misma anatomía, implementada en las tres herramientas líderes de tres dominios distintos. Lee la tabla de izquierda a derecha: la columna de la izquierda es la función; las otras tres son la misma función, con distinto disfraz.

Si algo de esta tabla te sorprende, casi seguro está en las filas 2 y 3, o en la 4. Ahí es donde el modelo se gana el sueldo. Vamos a esas tres.

Runner y herramientas: por qué son dos, no una

Este es el corte más útil de toda la anatomía, y el que casi nadie hace explícito.

El runner es el que manda el tráfico: descubre tus archivos de test, decide el orden, los corre en paralelo, reintenta el que falló, junta los resultados. No sabe nada de tu aplicación. Podrías cambiar toda tu app y el runner ni se entera.

Las herramientas son lo que efectivamente toca el sistema: el browser que hace clic, el cliente HTTP que dispara la request, el driver que tapea la pantalla del teléfono. Esa capa sí sabe de tu aplicación — es la que la manipula.

¿Por qué te importa separarlas? Porque el día que algo se rompe, el modelo te dice dónde mirar. ¿El test es inestable porque el orden de ejecución lo pisa con otro? Eso es el runner. ¿Es inestable porque el browser tardó en pintar el botón? Eso es la herramienta. Mismo síntoma —“falla a veces”—, dos piezas distintas, dos arreglos distintos. Si no las separas, cualquier falla intermitente termina con la misma etiqueta —“flaky”— y, como no sabes qué pieza la causó, la arreglas a tientas.

Donde mejor se ve todo esto es en Appium, porque las dos piezas están literalmente en dos ventanas distintas de tu pantalla.

En Playwright la separación existe igual, solo que más disimulada: @playwright/test es el runner, y por debajo el driver de Chromium habla por CDP con el browser. Vienen en el mismo paquete, pero son dos funciones. En k6 pasa lo mismo: el motor que sube y baja usuarios virtuales es el runner; el cliente HTTP que arma cada request es la herramienta.

El goal: donde el modelo demuestra que es agnóstico de verdad

La pieza 4 es la que más creemos entender y peor solemos aplicar. En la primera parada vimos que cada assert es un goal verificable: defines, por fuera del código que ejecutó, cuál es la condición de éxito.

En UI y en mobile eso se ve familiar: expect(page).toHaveURL("/dashboard"). Pasa o falla. Verde o rojo.

Ahora mira la columna de k6. El goal de performance no es pasa/falla. Es un umbral:

export const options = {
  thresholds: {
    // El goal no es "respondió". Es "respondió rápido, casi siempre".
    http_req_duration: ["p95<500"],
  },
};

“El percentil 95 de las respuestas por debajo de 500 ms.” Ese es el oráculo. No pregunta “¿funcionó?” — pregunta “¿funcionó lo bastante bien, para bastantes usuarios?”. Es un goal de forma completamente distinta, y sin embargo cumple exactamente la misma función que un expect de Playwright: es el criterio externo que decide si el resultado sirve.

Y ahí está la prueba de que este modelo no es un truco para vender Playwright. Si las seis piezas solo calzaran en herramientas de UI, serían la anatomía de Playwright, no la de un harness. El hecho de que el goal de k6 sea un threshold y no un booleano —y que aun así sea, sin dudas, la pieza número 4— es lo que te confirma que estás mirando el esqueleto, no la piel.

¿Y el loop? No es una séptima pieza

Si vienes siguiendo la serie —Loop, goal y harness— vas a estar esperando el loop en esta lista. No está. Y no es un olvido.

El loop no es una pieza del arnés. Es el arnés en movimiento. Las seis piezas son la anatomía: lo que hay, quieto, si abres el framework y lo miras por dentro. El loop es la fisiología: esas piezas funcionando.

Acuérdate del arrange-act-assert de la primera parada. Míralo ahora con la anatomía en la mano:

El loop es lo que pasa cuando las piezas se mueven juntas, una vez por caso, mil veces por suite. Por eso tiene su propia parada más adelante en la serie: la anatomía la desarmamos hoy; el movimiento —dónde empieza, dónde para— se lo dedicamos entero a otro día.

Por hoy quédate con esto: ese loop no es nada nuevo para ti. Es el arrange-act-assert de siempre —preparas, actúas, verificas, y si hace falta repites hasta cumplir la condición de parada—. Así que cuando alguien te muestre “su agentic loop” como si fuera una frontera de la ingeniería, ya sabes que es el mismo ciclo que tu suite corre todos los días.

La checklist: seis preguntas para cualquier framework

Acá está el takeaway que te prometí. Toma cualquier framework —el que vas a construir o el que heredaste el lunes pasado— y hazle estas seis preguntas. Una por pieza. Donde no encuentres respuesta clara, ahí está tu próximo trabajo.

Fíjate lo que hace esta checklist con un codebase heredado. Antes era “acá hay mil archivos y no entiendo nada”. Ahora es un recorrido de seis paradas: ubicas cada pieza, y las preguntas que quedan sin respuesta son exactamente lo que falta. En las suites heredadas, lo que más suele faltar es la 5 y la 6 — reporting pobre y cero orquestación. Con el modelo, lo ves en una tarde en vez de en un trimestre.

Lo que quiero que te lleves

Un framework de tests no es un misterio de mil archivos. Son seis funciones que toda herramienta resuelve, con distinto disfraz: prepara el estado, organiza los casos, toca el sistema, define lo correcto, cuenta qué pasó, y orquesta todo para que corra solo.

Playwright, k6 y Appium las implementan de forma distinta —un expect acá, un threshold allá, un server aparte más allá— y son las mismas seis. Por eso este modelo te sobrevive el cambio de herramienta: aprendes el esqueleto una vez, y después solo cambias la piel.

La próxima parada agarra uno de esos dos caminos, y capaz el que menos esperas: ponerle este mismo arnés a tu agente de IA. Las mismas seis piezas —herramientas, setup, goal, loop, reporting, reglas— envolviendo esta vez a tu agente en lugar de a tu código bajo prueba. Dirigir un agente de QA usa exactamente lo que ya sabes: le pones a un ejecutante distinto el arnés que armas para tus tests.

Y el otro camino —construir tu framework herramienta por herramienta, del primer flujo en Playwright al harness de carga en k6— también te espera, con todo lo que aprendiste hoy.