Verificar que los pedidos se rendericen correctamente en el dashboard es una de las pruebas más valiosas que puedes escribir en una aplicación con React. Aquí se construye paso a paso un test que utiliza mocks, dobles de acción y queries avanzadas de Testing Library para garantizar que lo que devuelve el endpoint de órdenes sea exactamente lo que el usuario ve en pantalla.
¿Por qué es importante mockear los servicios del dashboard?
El componente Orders es el corazón del gestor de pedidos. Cuando el usuario inicia sesión y llega a /orders, un useEffect interno llama a la función getOrders, que es una promesa que consulta un backend dummy corriendo en el puerto 3001 [00:08]. En el archivo db.json, dentro de la carpeta datasets, existe un arreglo llamado orders con toda la colección de datos que la aplicación consume [00:25].
Para que el test sea unitario y predecible, no se llama al backend real. En su lugar se mockean tanto getOrders como useSession, dos dependencias críticas del componente.
¿Cómo se estructura el archivo de test para orders?
Se crea el archivo orders.test.tsx dentro de src/containers/orders [00:35]. La estructura sigue el patrón habitual:
describe agrupa los tests del componente Orders.it define el caso de prueba: "debería mostrar las órdenes".- Se importan
render y screen desde Testing Library React, junto con vi desde Vitest.
¿Qué función cumple handleRenderOrders?
Se construye una función auxiliar llamada handleRenderOrders que recibe un parámetro userRole [02:45]. Dentro se invoca render envolviendo el componente con MemoryRouter y SessionProvider, exactamente como se hizo en el test del login. El mock del usuario se genera condicionalmente: si existe userRole, retorna { role: userRole }; si no, retorna null [03:10].
Esta aplicación maneja dos roles: super admin y visualizer. El visualizer es quien ve las órdenes en el gestor, por lo que el test arranca con ese rol [04:00].
¿Cómo se mockean useSession y getOrders?
El mock de useSession utiliza vi.mock apuntando a context/outContext. Para conservar las demás exportaciones del módulo se usa await vi.importActual, y solo se sobreescribe useSession como función [02:15]. Luego, dentro de handleRenderOrders, se llama a (useSession as Mock).mockReturnValue({ user: mockUser }), indicando que la sesión contiene un usuario válido [03:35].
Para getOrders se aplica el mismo concepto de doble de acción [04:50]:
- Se importa
getOrders desde services/getOrders.
- Se crea
const mockGetOrders = getOrders as Mock.
- Se llama a
mockGetOrders.mockResolvedValue(mockOrders), simulando que la promesa se resuelve con los datos preparados.
El arreglo mockOrders contiene una sola orden copiada directamente del db.json [02:00]. Esto permite controlar con precisión cuántos elementos debe renderizar el componente.
¿Cómo se valida que las órdenes se renderizan correctamente?
Dentro del it, tras invocar handleRenderOrders('visualizer'), se utiliza waitFor de Testing Library React porque la carga de órdenes es asíncrona y la función del test debe declararse como async [05:35].
Aquí aparece una query nueva: getAllByRole [05:15]. A diferencia de getByRole, que busca un solo elemento, getAllByRole devuelve un arreglo con todos los elementos que coincidan. Cada orden en el componente OrderItem contiene una etiqueta <h3>, así que la consulta queda:
tsx
const orders = screen.getAllByRole('heading', { level: 3 });
La aserción final verifica la longitud del arreglo:
tsx
expect(orders).toHaveLength(mockOrders.length);
Si mockOrders tiene una posición, el test espera exactamente un heading de nivel 3. Cambiar el valor esperado a 2 provoca un fallo inmediato, confirmando que la validación es real [06:05].
¿Qué metodologías de testing se han aplicado hasta ahora?
A lo largo del curso se han puesto en práctica distintas metodologías que fortalecen la calidad del código:
- Tests unitarios: validaciones aisladas de funciones y componentes.
- Table Driven Testing: ejecución de múltiples escenarios con datos tabulados.
- Test Driven Development (TDD): escribir el test antes del código, con la advertencia de que solo aplica para software que no es experimental [06:45].
Cuéntanos en la sección de aportes qué metodología o concepto te ha resultado más útil hasta el momento.
