¿Cómo estructurar Page Objects en SPAs extensas con componentes repetitivos?

Se utiliza la composición de componentes (Widget Objects). En lugar de una clase monolítica, se crean clases modulares (HeaderWidget, SidebarWidget, CartDrawerWidget) que encapsulan su propio localizador raíz. El Page Object principal agrega estos widgets como propiedades públicas readonly, replicando la jerarquía real de la aplicación.

¿Debe una clase Page Object contener aserciones expect()?

Existen dos corrientes. La postura pura de Fowler sugiere ubicar las aserciones exclusivamente en los tests. En el testing moderno de Playwright se aceptan dos clases de aserciones en POM: 1) Guard Assertions (validar que la página está lista antes de proceder); 2) Verificaciones semánticas (ej. expectOrderSuccessful()) que ocultan los selectores internos de estado a la prueba.

¿Cómo previene Locator Chaining fallos al manipular ventanas modales?

Locator Chaining confina la búsqueda al contenedor modal: modal.getByRole('button', { name: 'Guardar' }). Si la página de fondo bajo el modal contiene otro botón 'Guardar', una búsqueda global con page.getByRole() fallará por violación de modo estricto (Strict Mode Violation). Restringir el alcance al nodo padre asegura el clic exclusivamente sobre el modal.

¿Qué ventajas ofrece test.extend frente a los hooks clásicos beforeEach y al operador new?

test.extend aplica Inyección de Dependencias (IoC). Las fixtures se inicializan bajo demanda de forma perezosa: si una prueba no requiere una fixture, esta no se instancia. Además, encapsulan su propio Setup y Teardown, eliminando hooks hinchados. Permiten componer grafos de dependencias entre fixtures con resolución automática del orden de ejecución.

¿Cuál es la diferencia entre fixtures con alcance 'test' y alcance 'worker'?

Una fixture con ámbito 'test' (predeterminado) se instancia de nuevo para cada caso y se destruye al finalizar, asegurando aislamiento total. Una fixture con ámbito 'worker' ({ scope: 'worker' }) se inicializa una sola vez por hilo de trabajo y se comparte entre todas las pruebas de ese hilo. Se emplea para operaciones costosas como levantar bases de datos de prueba o generar tokens globales.

¿Qué sucede si una fixture dentro de una cadena falla durante su Setup?

Si una fixture arroja una excepción en Setup (antes de llamar a use()), la prueba no se ejecuta y se marca como fallida de inmediato. Sin embargo, Playwright garantiza que los bloques de Teardown de todas las fixtures que se hayan inicializado con éxito previamente se ejecuten, evitando recursos huérfanos o fugas en base de datos.

¿Es posible suministrar parámetros desde una prueba concreta a una fixture personalizada?

Sí, mediante opciones de fixture (options). Se declara la fixture con un valor por omisión y se sobreescribe en pruebas individuales o bloques describe mediante test.use({ myOption: 'valor' }). La fixture consume dinámicamente este valor para modular su comportamiento (por ejemplo, crear usuarios con un rol o configuración regional específica).

Patrón Page Object Model (POM) y Fixtures Limpias — Pruebas y Automatización QA

Base Arquitectónica#

En las suites de pruebas E2E desestructuradas, los selectores del DOM y las instrucciones de bajo nivel residen directamente en el cuerpo de las funciones de prueba. Esta práctica desencadena tres problemas críticos de arquitectura:

Degradación en cascada del mantenimiento: Modificar el identificador de un botón en la interfaz obliga al equipo a alterar manualmente decenas de archivos de prueba dispersos.
Difuminación del propósito de negocio: Las pruebas quedan anegadas de detalles imperativos (búsqueda de nodos, clics con desplazamiento, pausas, rellenado de inputs), perdiendo la claridad sobre el requisito funcional evaluado.
Duplicación endémica de código instrumental: Flujos operativos recurrentes (autenticación, vaciado de cesta, captura de datos de facturación) se propagan mediante patrones de copiar y pegar.

El patrón Page Object Model (POM) soluciona este dilema disociando la estructura del marcado visual de la lógica de verificación.

No obstante, la implementación tradicional de POM heredada de Java y Selenium—donde las páginas se instancian manualmente con new MyPage(page) en bloques beforeEach—está obsoleta. En el ecosistema de Playwright 2026, el estándar imperante fusiona los Page Objects con la Inyección de Dependencias (IoC) respaldada por Fixtures Personalizadas (Custom Fixtures).

Modelo Mental#

Bajo una arquitectura de testing limpia, un escenario de prueba jamás interactúa directamente con el DOM en bruto. Se comunica exclusivamente a través de interfaces de dominio de alto nivel (Domain Pages & Widgets) inyectadas por el contenedor de Playwright.

text

+-----------------------------------------------------------------------------+
|                                Test Runner                                  |
|   test('usuario adquiere plan Enterprise', async ({ checkoutPage }) => {})  |
+-----------------------------------------------------------------------------+
                                       │
                                       ▼ (Inyección de dependencia vía IoC)
+-----------------------------------------------------------------------------+
|                    Playwright Fixtures Engine (test.extend)                 |
|   Setup automático -> Instanciación de páginas -> Teardown de recursos      |
+-----------------------------------------------------------------------------+
                                       │
                                       ▼ (Invocación de métodos de dominio)
+-----------------------------------------------------------------------------+
|                         Page Object Model Layer                             |
|                                                                             |
|   +--------------------------+           +------------------------------+   |
|   |       ShopPage           |           |        CheckoutPage          |   |
|   |  - selectProduct()       |           |  - fillPaymentDetails()      |   |
|   |  - openCart()            |           |  - placeOrder()              |   |
|   +--------------------------+           +------------------------------+   |
|                 │                                       │                   |
|                 ▼ (Composición)                         ▼ (Composición)     |
|   +--------------------------+           +------------------------------+   |
|   |   HeaderNavigationWidget |           |      NotificationToastWidget |   |
|   +--------------------------+           +------------------------------+   |
+-----------------------------------------------------------------------------+
                                       │
                                       ▼ (Localizadores getByRole encapsulados)
+-----------------------------------------------------------------------------+
|                           Playwright Core Driver                            |
|             Page API -> Chrome DevTools Protocol / WebDriver BiDi           |
+-----------------------------------------------------------------------------+
                                       │
                                       ▼ (Eventos físicos de ratón/teclado)
+-----------------------------------------------------------------------------+
|                               Browser DOM                                   |
+-----------------------------------------------------------------------------+

Page Object: Representación lógica de una pantalla.
Widget / Component Object: Objeto de componente de página.
Locator Chaining: Acotación del ámbito de evaluación.
Fixture Teardown: Limpieza garantizada tras la ejecución de pruebas.

Sintaxis y API#

1. Arquitectura de una Clase Page Object en TypeScript#

Siguiendo estándares de nivel empresarial, los localizadores se declaran como propiedades readonly de tipo Locator. El constructor recibe la instancia de Page.

typescripte2e/pages/CheckoutPage.ts

import { type Page, type Locator, expect } from '@playwright/test';

export interface PaymentInfo {
  cardNumber: string;
  cardHolder: string;
  expiryDate: string;
  cvv: string;
}

export class CheckoutPage {
  // Localizadores encapsulados orientados al usuario (User-Facing)
  private readonly pageTitle: Locator;
  private readonly cardNumberInput: Locator;
  private readonly cardHolderInput: Locator;
  private readonly expiryInput: Locator;
  private readonly cvvInput: Locator;
  private readonly submitOrderButton: Locator;
  private readonly successBanner: Locator;
  private readonly errorMessageContainer: Locator;

  constructor(private readonly page: Page) {
    this.pageTitle = page.getByRole('heading', { name: 'Tramitar Pedido', level: 1 });
    this.cardNumberInput = page.getByLabel('Número de tarjeta');
    this.cardHolderInput = page.getByLabel('Titular de la tarjeta');
    this.expiryInput = page.getByPlaceholder('MM/AA');
    this.cvvInput = page.getByLabel('CVV/CVC');
    this.submitOrderButton = page.getByRole('button', { name: 'Confirmar y pagar' });
    this.successBanner = page.getByRole('status').filter({ hasText: /pedido tramitado con éxito/i });
    this.errorMessageContainer = page.getByRole('alert');
  }

  /** Navegación hacia la ruta de checkout */
  async navigate(): Promise<void> {
    await this.page.goto('/checkout');
    await expect(this.pageTitle).toBeVisible();
  }

  /** Relleno integral del formulario de pago */
  async fillPaymentForm(info: PaymentInfo): Promise<void> {
    await this.cardNumberInput.fill(info.cardNumber);
    await this.cardHolderInput.fill(info.cardHolder);
    await this.expiryInput.fill(info.expiryDate);
    await this.cvvInput.fill(info.cvv);
  }

  /** Confirmación del pedido */
  async submitOrder(): Promise<void> {
    await this.submitOrderButton.click();
  }

  /** Verificación de tramitación exitosa */
  async expectOrderSuccessful(): Promise<void> {
    await expect(this.successBanner).toBeVisible({ timeout: 10_000 });
  }

  /** Verificación de mensaje de error de validación */
  async expectValidationError(message: string): Promise<void> {
    await expect(this.errorMessageContainer).toContainText(message);
  }
}

2. Extensión del Test Runner: Método `test.extend`#

En lugar de instanciar clases manualmente en cada archivo, extendemos el ejecutor base con test.extend<T>() para habilitar inyección de dependencias tipada:

typescript

import { test as baseTest } from '@playwright/test';

// 1. Declaración de la interfaz de fixtures
export interface AppFixtures {
  checkoutPage: CheckoutPage;
  catalogPage: CatalogPage;
}

// 2. Creación del runner con ciclo de vida automatizado
export const test = baseTest.extend<AppFixtures>({
  checkoutPage: async ({ page }, use) => {
    // Fase SETUP: instanciación del Page Object
    const checkoutPage = new CheckoutPage(page);

    // Cesión del control al cuerpo de la prueba
    await use(checkoutPage);

    // Fase TEARDOWN (se ejecuta automáticamente tras la prueba)
  },

  catalogPage: async ({ page }, use) => {
    const catalogPage = new CatalogPage(page);
    await use(catalogPage);
  },
});

export { expect } from '@playwright/test';

Patrones Prácticos#

1. Composición de Widgets (Component Objects) dentro de Páginas#

Las aplicaciones de gran envergadura comparten estructuras comunes: Cabeceras (Header), Barras laterales (Sidebar), Cajón del carrito (CartDrawer) y Notificaciones. Desarrollar Page Objects monolíticos de mil líneas es un antipatrón; descomponer en widgets asegura modularidad.

typescripte2e/widgets/HeaderWidget.ts

import { type Page, type Locator, expect } from '@playwright/test';

export class HeaderWidget {
  private readonly root: Locator;
  private readonly cartButton: Locator;
  private readonly cartBadge: Locator;
  private readonly searchInput: Locator;
  private readonly userMenuButton: Locator;

  constructor(page: Page) {
    // Encapsulamos el contenedor raíz de la cabecera
    this.root = page.getByRole('banner');
    this.cartButton = this.root.getByRole('button', { name: /carrito/i });
    this.cartBadge = this.cartButton.getByTestId('cart-items-count');
    this.searchInput = this.root.getByRole('searchbox', { name: /buscar productos/i });
    this.userMenuButton = this.root.getByRole('button', { name: /perfil de usuario/i });
  }

  async openCart(): Promise<void> {
    await this.cartButton.click();
  }

  async searchProduct(query: string): Promise<void> {
    await this.searchInput.fill(query);
    await this.searchInput.press('Enter');
  }

  async expectCartItemCount(count: number): Promise<void> {
    if (count === 0) {
      await expect(this.cartBadge).toBeHidden();
    } else {
      await expect(this.cartBadge).toHaveText(String(count));
    }
  }
}

Ahora la página ShopPage compone dicho HeaderWidget:

typescripte2e/pages/ShopPage.ts

import { type Page, type Locator } from '@playwright/test';
import { HeaderWidget } from '../widgets/HeaderWidget';

export class ShopPage {
  public readonly header: HeaderWidget;
  private readonly productList: Locator;

  constructor(private readonly page: Page) {
    this.header = new HeaderWidget(page);
    this.productList = page.getByRole('main').getByRole('list');
  }

  async navigate(): Promise<void> {
    await this.page.goto('/shop');
  }

  async addProductToCart(productName: string): Promise<void> {
    const productCard = this.productList.getByRole('listitem').filter({
      hasText: productName,
    });
    await productCard.getByRole('button', { name: /añadir a la cesta/i }).click();
  }
}

2. Fixture con Teardown Automático y Siembra Aislada de Datos#

Este patrón garantiza que cada prueba trabaje con entidades únicas sembradas vía API y limpie sus registros automáticamente tras la ejecución, impidiendo la degradación de la base de datos de pruebas.

typescripte2e/fixtures/test-suite.ts

import { test as baseTest, expect } from '@playwright/test';
import { ShopPage } from '../pages/ShopPage';
import { CheckoutPage } from '../pages/CheckoutPage';

export interface TestUser {
  id: string;
  email: string;
  token: string;
}

export interface CustomFixtures {
  shopPage: ShopPage;
  checkoutPage: CheckoutPage;
  temporaryCustomer: TestUser;
}

export const test = baseTest.extend<CustomFixtures>({
  // Fixture para crear un cliente efímero aislado vía API
  temporaryCustomer: async ({ request }, use) => {
    // 1. SETUP: Sembrar usuario único mediante petición HTTP veloz
    const uniqueId = `e2e_${Date.now()}_${Math.random().toString(36).substring(7)}`;
    const createRes = await request.post('/api/testing/create-ephemeral-user', {
      data: {
        email: `${uniqueId}@agenticlab-test.internal`,
        role: 'customer',
      },
    });

    expect(createRes.ok()).toBeTruthy();
    const customer = (await createRes.json()) as TestUser;

    // 2. YIELD: ceder la entidad al contexto de la prueba
    await use(customer);

    // 3. TEARDOWN: eliminación garantizada del usuario tras la prueba
    const deleteRes = await request.delete(`/api/testing/cleanup-user/${customer.id}`, {
      headers: { Authorization: `Bearer ${customer.token}` },
    });
    expect(deleteRes.ok()).toBeTruthy();
  },

  shopPage: async ({ page }, use) => {
    const shopPage = new ShopPage(page);
    await use(shopPage);
  },

  checkoutPage: async ({ page }, use) => {
    const checkoutPage = new CheckoutPage(page);
    await use(checkoutPage);
  },
});

export { expect };

3. Prueba E2E Declarativa sin Acceso Directo al DOM#

Combinando POM y fixtures personalizadas, el escenario resulta conciso, legible y resistente a alteraciones cosméticas de marcado:

typescripte2e/specs/e-commerce-purchase.spec.ts

import { test, expect } from '../fixtures/test-suite';

test.describe('Comercio Electrónico: Tramitación de Pedidos', () => {
  test('el cliente añade un artículo a la cesta y concluye el pago', async ({
    shopPage,
    checkoutPage,
    temporaryCustomer,
  }) => {
    // 1. Navegación a la tienda
    await shopPage.navigate();

    // 2. Incorporar producto y verificar contador mediante widget compuesto
    await shopPage.addProductToCart('Curso de Arquitectura React 19');
    await shopPage.header.expectCartItemCount(1);

    // 3. Acceder al checkout desde la cabecera
    await shopPage.header.openCart();
    await checkoutPage.navigate();

    // 4. Completar datos con la entidad sembrada
    await checkoutPage.fillPaymentForm({
      cardNumber: '4000 1234 5678 9010',
      cardHolder: temporaryCustomer.email.toUpperCase(),
      expiryDate: '12/28',
      cvv: '789',
    });

    // 5. Tramitar y verificar resultado
    await checkoutPage.submitOrder();
    await checkoutPage.expectOrderSuccessful();
  });
});

Errores Comunes#

Ошибка: Exponer localizadores o nodos DOM crudos fuera del Page Object

Cuando los métodos del POM devuelven instancias de Locator al exterior, la prueba compradora se acopla a la estructura interna del DOM, quebrando el principio de encapsulación.

typescript

// ❌ INCORRECTO: La página expone el localizador en bruto
export class CartPage {
  getCheckoutButton(): Locator {
    return this.page.locator('#btn-checkout-submit');
  }
}
// En la prueba:
await cartPage.getCheckoutButton().click();

// ✅ CORRECTO: Encapsular la acción y verificar estados dentro del POM
export class CartPage {
  async proceedToCheckout(): Promise<void> {
    await this.page.getByRole('button', { name: 'Ir al pago' }).click();
  }
}

Ошибка: Instanciar páginas manualmente con new PageObject(page) en beforeEach

Crear páginas manualmente mediante new en bloques beforeEach anula la inicialización perezosa de Playwright y complica la gestión de dependencias compartidas.

typescript

// ❌ INCORRECTO: beforeEach farragoso con instanciación manual
let loginPage: LoginPage;
let dashboardPage: DashboardPage;

test.beforeEach(async ({ page }) => {
  loginPage = new LoginPage(page);
  dashboardPage = new DashboardPage(page);
});

// ✅ CORRECTO: Inyección de dependencias limpia con test.extend
test('inicio de sesión exitoso', async ({ loginPage, dashboardPage }) => {
  await loginPage.login('[email protected]', 'password');
  await dashboardPage.expectLoaded();
});

Ошибка: Olvidar await antes de use() en fixtures personalizadas

Omitir await al invocar use() o no llamarlo en absoluto impide que Playwright transfiera el control a la prueba, provocando bloqueos indefinidos hasta expirar los timeouts del worker.

typescript

// ❌ INCORRECTO: Falta await o se omite use
myFixture: async ({ page }, use) => {
  const service = new MyService(page);
  use(service); // Error: no aguarda la resolución de la prueba
}

// ✅ CORRECTO: Aguardar imperativamente la ejecución del test
myFixture: async ({ page }, use) => {
  const service = new MyService(page);
  await use(service); // Suspende la ejecución hasta que la prueba concluye
}

Ошибка: Intercalar aserciones de negocio dentro de utilidades de interacción

Los métodos instrumentales (como fillForm()) no deben incorporar aserciones propias de escenarios concretos. Si un método de entrada valida un título específico, quedará inhabilitado para pruebas negativas (ej. verificar la reacción ante emails inválidos).

Proceso Paso a Paso para Diseñar Fixtures Limpias#

Ciclo de vida de una fixture personalizada en Playwright

Declaración de interfaces en TypeScriptTypeScript Interface

Definir CustomFixtures enumerando Page Objects, contextos y generadores de datos inyectables.

Fase de Setup e inicializaciónSetup Phase

Se ejecuta antes del test: instancia Page Objects, realiza llamadas backend o siembra datos.

Llamada a await use(instance)Yield Control

Cede el control al cuerpo del test. La función de fixture se pausa mientras transcurre la prueba.

Ejecución del escenario de pruebaTest Execution

El test invoca métodos de la fixture sin acceder al DOM crudo.

Fase de Teardown y limpieza garantizadaTeardown Cleanup

El código posterior a await use() se ejecuta siempre: elimina entidades y libera recursos.

Preguntas de Entrevista#

Preguntas de entrevista7 preguntas

Temas Relacionados#

Temas relacionados

Arquitectura de Playwright 2026: CDP, Aislamiento y Auto-waiting— Mecanismos de bajo nivel de control del navegador y Actionability Checks.Gestión de Autenticación y Storage State— Reutilización de estados de sesión autenticados entre fixtures.Interceptación de Red y Simulación HAR en Playwright— Uso de fixtures para simular respuestas de API en red.Pruebas de Componentes con Vitest y RTL— Pruebas de componentes aislados a nivel de integración.

Patrón Page Object Model (POM) y Fixtures Limpias

Base Arquitectónica#

Modelo Mental#

Sintaxis y API#

1. Arquitectura de una Clase Page Object en TypeScript#

2. Extensión del Test Runner: Método test.extend#

Patrones Prácticos#

1. Composición de Widgets (Component Objects) dentro de Páginas#

2. Fixture con Teardown Automático y Siembra Aislada de Datos#

3. Prueba E2E Declarativa sin Acceso Directo al DOM#

Errores Comunes#

Ошибка: Exponer localizadores o nodos DOM crudos fuera del Page Object

Ошибка: Instanciar páginas manualmente con new PageObject(page) en beforeEach

Ошибка: Olvidar await antes de use() en fixtures personalizadas

Ошибка: Intercalar aserciones de negocio dentro de utilidades de interacción

Proceso Paso a Paso para Diseñar Fixtures Limpias#

Preguntas de Entrevista#

Temas Relacionados#

Base Arquitectónica#

Modelo Mental#

Sintaxis y API#

1. Arquitectura de una Clase Page Object en TypeScript#

2. Extensión del Test Runner: Método test.extend#

Patrones Prácticos#

1. Composición de Widgets (Component Objects) dentro de Páginas#

2. Fixture con Teardown Automático y Siembra Aislada de Datos#

3. Prueba E2E Declarativa sin Acceso Directo al DOM#

Errores Comunes#

Ошибка: Exponer localizadores o nodos DOM crudos fuera del Page Object

Ошибка: Instanciar páginas manualmente con new PageObject(page) en beforeEach

Ошибка: Olvidar await antes de use() en fixtures personalizadas

Ошибка: Intercalar aserciones de negocio dentro de utilidades de interacción

Proceso Paso a Paso para Diseñar Fixtures Limpias#

Preguntas de Entrevista#

Temas Relacionados#

2. Extensión del Test Runner: Método `test.extend`#

2. Extensión del Test Runner: Método `test.extend`#