Crear un framework de automatización no es escribir tests: es diseñar una plataforma

Hay una parte de crear Athenas Base que me ordenó bastante la cabeza: en algún momento dejó de sentirse como “armar tests” y empezó a sentirse como diseñar una plataforma.

No pasó de golpe. Al principio uno piensa en lo obvio: Playwright, estructura de carpetas, Page Objects, steps, fixtures, comandos para correr smoke y regresión. Cosas necesarias, sí. Pero después aparecen preguntas más incómodas.

¿Cómo hace alguien que no estuvo en tu cabeza para entender por dónde empezar? ¿Qué pasa cuando el test falla? ¿Dónde queda la evidencia? ¿Qué decisión querés permitir y cuál querés bloquear antes de que se convierta en deuda? ¿Cuánto de la arquitectura se explica sola y cuánto depende de que vos estés cerca?

Ahí el problema cambia.

Ya no estás intentando que un test pase. Estás intentando que una forma de trabajar sea repetible.

La primera versión siempre parece más chica de lo que es

Cuando empecé a pensar Athenas como base, la idea era bastante concreta: tener una estructura de automatización E2E que pudiera clonarse, adaptarse a un producto real y conservar lo importante ya resuelto.

Una base con Playwright para web, Allure para evidencia, una arquitectura clara de selectors -> page object -> steps -> spec, un runner propio para no depender de comandos raros según el sistema operativo y validadores que cuiden ciertas reglas antes de mergear.

Dicho así, parece un checklist técnico.

Pero en la práctica cada punto abre otra puerta.

Si tenés un runner, tenés que pensar cómo se usa en local, en CI, en Windows, en Linux, con distintos módulos y con distintos sitios. Si tenés reporting, tenés que decidir qué evidencia sirve y qué ruido conviene sacar. Si tenés una arquitectura por capas, tenés que hacerla cumplir sin convertirla en una religión molesta. Si tenés una base genérica, tenés que evitar que el ejemplo demo se mezcle con lo que después debería reemplazar un equipo.

Y esa es la diferencia: escribir tests te pide resolver un caso. Diseñar una plataforma te pide resolver el uso repetido de muchos casos, por personas distintas y en contextos distintos.

La arquitectura también es una forma de enseñar

Hay decisiones técnicas que no están solo para que el código quede prolijo.

Separar selectores, páginas, pasos y specs no es una manía estética. Es una manera de decir: cada capa tiene una responsabilidad, y si mezclás todo en el spec, tarde o temprano vas a pagar esa comodidad.

El spec debería contar el comportamiento. El step debería expresar la acción de negocio. El Page Object debería saber interactuar con la pantalla. El selector debería quedar en un lugar donde se pueda cambiar sin revisar veinte archivos.

Eso parece básico hasta que tenés que sostener una suite durante meses.

Lo interesante de construir una base es que no alcanza con saber esa regla. Tenés que dejarla escrita en la estructura, en los ejemplos, en los nombres, en los validadores y en la documentación. Porque si la convención vive solamente en tu memoria, no es una convención: es una dependencia humana.

A mí esa parte me parece muy importante. Un framework interno enseña incluso cuando nadie está explicando nada. Enseña con los caminos que facilita y también con los caminos que bloquea.

El runner no es un detalle menor

Antes subestimaba un poco esta parte.

Uno puede correr playwright test y listo. Técnicamente alcanza. Pero cuando querés que una base sea usable por más gente, el comando también forma parte de la experiencia.

En Athenas Base aparece qa-run como una CLI propia. No porque haga falta inventar una capa por capricho, sino porque te permite ordenar cómo se ejecutan los módulos, cómo se selecciona un sitio, cómo se corre un smoke, una regresión, una spec puntual o una suite mobile sin pedirle a cada persona que memorice combinaciones largas de flags.

Esa decisión parece chica, pero baja fricción.

Y bajar fricción importa, porque la adopción de una herramienta interna no se gana con una charla inspiradora. Se gana cuando alguien necesita validar algo, ejecuta un comando razonable, obtiene evidencia clara y no pierde media tarde peleándose con la base.

La evidencia define la confianza

Un framework de automatización se luce cuando está verde, pero se gana la confianza cuando está rojo.

Si falla y nadie entiende por qué, el equipo aprende algo muy rápido: “mejor no tocarlo”.

Por eso el reporte no puede ser un accesorio. En una plataforma de automatización, la evidencia es parte del producto. Screenshots, videos, traces, pasos de negocio, attachments curados, logs útiles. Todo eso existe para que una falla no sea un acertijo.

Esto se nota mucho cuando intentás cubrir distintos tipos de automatización: web, API, batch, mobile, visual. Cada módulo necesita evidencia distinta. No todo se diagnostica mirando una pantalla. A veces el valor está en un request, en una respuesta redactada, en un XML saneado, en un archivo exportado, en un video mobile o en una comparación visual que no debería actualizarse por accidente.

Ahí dejás de pensar en “reportes lindos” y empezás a pensar en trazabilidad.

La pregunta no es si el reporte se ve bien. La pregunta es si ayuda a tomar una decisión.

Los validadores son una forma de cuidar el futuro

Una de las cosas que más me gusta de este tipo de bases es meter reglas automáticas para evitar que la arquitectura se degrade de a poco.

Porque se degrada. Siempre.

No por mala intención. Se degrada por apuro, por desconocimiento, por copiar un ejemplo viejo, por resolver un bloqueo rápido, por dejar “después lo acomodamos”. Y ese después suele llegar tarde.

Por eso tienen sentido validadores de arquitectura, tags, scaffolds pendientes o patrones que no deberían entrar. No como policía del código, sino como borde de contención.

El validador no reemplaza una revisión técnica. Pero evita que ciertas discusiones se repitan para siempre. Te permite decir: esto no depende de si hoy alguien se acordó de mirarlo; la base lo cuida.

Ese tipo de decisiones son aburridas de vender, pero valen muchísimo cuando el proyecto crece.

Diseñar una base genérica te obliga a separar lo propio de lo reusable

Esta fue otra lección.

Cuando armás una automatización para un producto específico, podés permitirte atajos contextuales. Sabés cuál es el login, qué datos existen, qué URL usar, qué flujo importa, qué rareza del ambiente hay que tolerar.

Pero una base como Athenas Base tiene otro problema: tiene que mostrar un patrón completo sin quedar pegada al ejemplo.

El demo tiene que enseñar. No debería invadir.

Eso te obliga a pensar mejor los límites: configuración por sitio, credenciales por entorno, nombres que puedan reemplazarse, módulos separados, ejemplos suficientemente reales para copiar el patrón, pero no tan específicos como para ensuciar la base.

Es una tensión rara. Si el ejemplo es demasiado mínimo, no enseña nada. Si es demasiado grande, parece producto terminado y cuesta adaptarlo.

Encontrar ese punto medio es parte del diseño de plataforma.

La documentación no viene después

Algo que me pasa seguido: mientras construyo, siento que todo está claro. Sé por qué existe un comando, por qué un archivo está en ese lugar, por qué una regla valida cierta capa, por qué mobile corre con WDIO y web con Playwright, por qué el MCP sirve para explorar pero no reemplaza la ejecución real.

Claro que lo sé. Lo estoy armando yo.

El problema es que una plataforma no puede depender de ese contexto personal.

Por eso la documentación no es el trámite final antes de cerrar. Es parte del diseño. Te obliga a explicar qué decisiones tomaste y, muchas veces, te muestra que una decisión todavía no estaba tan clara.

Cuando escribir el README cuesta demasiado, a veces no es un problema de redacción. A veces es una señal de que la experiencia de uso todavía está desordenada.

Eso me pasó varias veces: documentar algo y darme cuenta de que el comando podía ser más simple, que el nombre no ayudaba, que faltaba un ejemplo o que una regla estaba escondida en un lugar donde nadie la iba a buscar.

La plataforma también tiene que poner límites

Hay una tentación grande de hacer que el framework permita todo.

Todo tipo de test, cualquier estructura, cualquier nombre, cualquier helper, cualquier forma de reportar, cualquier excepción. Suena flexible, pero muchas veces es simplemente ausencia de criterio.

Una plataforma útil no debería obligarte a pedir permiso para cada cosa. Pero sí debería dejar claro cuál es el camino esperado.

En automatización eso se nota mucho. Si cada módulo inventa su propio estilo, la suite se vuelve difícil de leer. Si cada spec arma sus datos como quiere, la estabilidad se rompe. Si cada persona reporta pasos de una manera distinta, después nadie compara nada. Si los tags no tienen sentido, correr una regresión deja de ser una operación confiable.

Los límites no están para frenar. Están para que el equipo pueda avanzar sin romper el piso.