====== 07 - Pruebas E2E: Playwright ======

Una prueba **E2E** (*end-to-end*) ejecuta el sistema completo — interfaz, servidor y datos — como lo haría un usuario real: abre la aplicación en un navegador, interactúa con ella y comprueba el resultado visible. **Playwright** automatiza el navegador.

===== 1. Qué se prueba =====

  * **Flujos críticos:** login, registro, compra, alta de datos. Pocos y bien elegidos.
  * **La integración de todo:** que la interfaz, la API y la base de datos funcionan juntas.
  * **Lo que el usuario ve:** el resultado visible de la operación, no los detalles internos.

No se prueba cada regla de negocio con E2E: eso corresponde a las pruebas unitarias. Cada prueba E2E cubre un camino completo.

===== 2. Playwright =====

**Playwright** controla un navegador real (Chromium, Firefox, WebKit) desde código Java:

<sxh java>
public class LoginE2eTest {
    @Test
    void logsInAndShowsWelcome() {
        try (Playwright playwright = Playwright.create()) {
            Browser browser = playwright.chromium().launch();
            Page page = browser.newPage();

            page.navigate("http://localhost:8080/login");
            page.fill("#email", "ana@example.com");
            page.fill("#password", "secret-password");
            page.click("button[type=submit]");

            assertThat(page.locator(".welcome"))
                    .hasText("Welcome, Ana");
        }
    }
}
</sxh>

^ Elemento ^ Función ^
| ''Playwright.create()'' | Inicia el motor de navegadores |
| ''Page'' | Representa la pestaña abierta |
| ''fill'', ''click'' | Interactúan con los elementos |
| ''Locator'' | Localiza un elemento por selector |
| ''assertThat'' | Comprueba el estado visible |

===== 3. Espera automática =====

Playwright **espera automáticamente** a que los elementos estén listos antes de interactuar: no hace falta dormir entre acciones. Las comprobaciones reintentan hasta que la condición se cumple o se agota el tiempo de espera.

===== 4. Buenas prácticas =====

  * **Datos controlados:** cada prueba crea o usa datos conocidos; si toca la base de datos, se prepara y se limpia.
  * **Selectores estables:** preferir atributos semánticos (''id'', atributos ''data-testid'', roles accesibles) a clases de estilo, que cambian con el diseño.
  * **Independientes:** cada prueba puede ejecutarse sola y en cualquier orden.
  * **Pocas:** la pirámide se apoya en las unitarias; E2E cubre los flujos que, si fallan, rompen el producto.

<note warning>Las pruebas E2E son las más lentas y frágiles de la pirámide. Si cada cambio rompe diez pruebas de interfaz por un selector cambiado, el coste supera el beneficio: prioriza flujos críticos y selectores estables.</note>