Lección 2 de 6 · 3 min
Arquitectura de una suite que aguanta crecer
Al terminar sabrás
10 min- Separar la suite en capas: test (qué), dominio (acciones) y técnica (cómo)
- Escribir tests que se lean en lenguaje de negocio
- Ubicar cada cambio en una sola capa
Construyes: El diseño en capas de una suite, con un test que se lee como una frase de negocio.
El síntoma: un cambio, cuarenta archivos
Cambian el botón de "Reservar" a "Agendar" y tienes que editar 40 tests. Eso no es mala suerte: es una suite sin arquitectura, donde el cómo (el selector) está copiado por todas partes en vez de vivir en un solo lugar.
Las tres capas
┌─────────────────────────────────────┐
│ 1. TEST → el QUÉ (negocio) │ reservar_hora_disponible()
├─────────────────────────────────────┤
│ 2. DOMINIO → las ACCIONES │ reservas.reservar('Corte','15:30')
├─────────────────────────────────────┤
│ 3. TÉCNICA → el CÓMO (herramienta)│ getByRole('button', {...}).click()
└─────────────────────────────────────┘
Capa 1 — Test. Se lee como una frase de negocio. Cualquiera del equipo lo entiende, sepa o no de Playwright:
test('reservar una hora disponible deja la reserva confirmada', async ({ reservas }) => {
const confirmacion = await reservas.reservar('Corte', '15:30');
await expect(confirmacion.mensaje()).toContain('reservada');
});
Capa 2 — Dominio. Traduce lenguaje de negocio a pasos. Aquí viven los page objects y los helpers. Es la capa que da el vocabulario.
Capa 3 — Técnica. Selectores, esperas, clics, la API de la herramienta. Nada de esto sube a la capa 1.
Por qué esto importa más de lo que parece
Una suite mal estructurada no falla de golpe: se muere de a poco. Cada refactor cuesta un poco más, cada test nuevo se copia-pega del anterior, y llega el día en que arreglar la suite cuesta más que borrarla. Ese día alguien propone "mejor la rehacemos" y se pierden años de conocimiento.
Las capas son lo que evita esa muerte lenta. No es sobre-ingeniería: es la diferencia entre una suite de 2 años y una de 2 meses.
Reglas prácticas
- Ningún selector en un archivo de test. Nunca. Si ves un
By.o ungetByRoleen la capa 1, está mal ubicado. - Ninguna assertion en la capa de dominio. El page object informa (devuelve datos), el test juzga.
- Los métodos de dominio devuelven objetos de dominio, para que la navegación quede encadenable y tipada.
- Si un helper crece sin control, es un síntoma, no una solución. Ver la próxima lección.
No confundas capas con carpetas
Puedes tener una estructura de carpetas preciosa y una suite pésima si los selectores igual están en los tests. Las capas son una disciplina, no un árbol de directorios. La carpeta ayuda; lo que manda es dónde vive cada responsabilidad.
Comprueba el criterio en el quiz y diseña tus capas en el reto.
Compruébalo
0/3Responde sin mirar atrás. Verás la explicación al instante.
1. ¿Cuál es el objetivo de separar la suite en capas?
2. ¿Cómo debería leerse un buen test de la capa superior?
3. Cambia el diseño de la página de login y el selector del botón. En una suite bien armada, ¿cuántos archivos tocas?
Reto: diseña las capas
Para un flujo de reserva (elegir servicio, elegir hora, confirmar datos, ver confirmación), escribe cómo se vería el test de la capa superior y qué acciones vivirían en la capa de dominio.