Cuando una vista cambia según el rol del usuario, tus pruebas también deben adaptarse. Aquí aprendes a testear un componente que solo se renderiza para superadmins usando React Testing Library, junto con la query getByTestId, ideal para casos donde un valor numérico aparece repetido en pantalla.

¿Cómo renderizar un componente solo visible para superadmins?

En Platzi Orders, la sección Order Summary muestra el total de órdenes, el total de ventas y el promedio. Pero esa sección no aparece para todos: depende del rol.

El componente usa una función llamada handleValidateUserAdmin que valida si el rol corresponde a superadmin. Si no lo es, el resumen no se monta. Por eso, en el caso de prueba debes pasar explícitamente ese rol al renderizar.

¿Qué cambia respecto a un test con rol visualizer?

En la prueba anterior usaste el rol visualizer. Ahora copias el rol superadmin desde el componente y lo envías a handleRenderOrders dentro del nuevo caso de prueba: "Debería mostrar sección para superadmins". Ese pequeño cambio activa todo el bloque que necesitas evaluar.

Después preparas el mockGetOrders para que retorne las órdenes simuladas y envuelves la lógica en waitFor, lo que obliga a declarar la función como asíncrona y usar await.

¿Qué hace waitFor en una prueba? Espera a que un elemento o condición aparezca tras una operación asíncrona, como una llamada a una API mockeada. Sin él, la aserción se ejecutaría antes de que el componente termine de renderizar.

¿Por qué getByText falla cuando el valor es un número repetido?

Al usar screen.getByText para buscar el total de órdenes, aparece un error: hay múltiples elementos con el valor 1 en la vista. Y tiene sentido, porque en una aplicación real un 1 puede estar en una lista, un contador, un badge o cualquier otro nodo.

Ahí entra getByTestId. Piénsalo como el equivalente a un id en CSS: un identificador único que asignas al elemento exacto que quieres inspeccionar.

¿Cómo se aplica data-testid en el componente?

Dentro de Order Summary, en la etiqueta p que muestra el total, agregas el atributo data-testid con el valor totalOrders. React Testing Library reconoce ese atributo y lo expone para tus pruebas.

Luego, en el test:

• Importas la utilidad getSummaryOrders desde la carpeta utils.
• Le pasas mockOrders para obtener el valor esperado de totalOrders.
• Buscas el nodo con screen.getByTestId('totalOrders').
• Comparas su contenido con el valor calculado.

¿Cuándo debo usar getByTestId? Solo cuando no encuentras el elemento por texto, rol o label. Es el último recurso, porque acopla tu test a detalles de implementación en lugar de a la experiencia del usuario.

¿Cómo comparar el valor renderizado contra el valor esperado?

Al hacer la primera aserción, aparece otro error: getByTestId devuelve el nodo completo, no su texto. La solución es leer .textContent del elemento.

Pero todavía falta un detalle. La utilidad getSummaryOrders retorna totalOrders como número, mientras que textContent devuelve un string. Tienes dos caminos:

1. Convertir el resultado de la utilidad a string.
2. Convertir el textContent a número.

Cualquiera funciona. En este flujo se elige transformar totalOrders a string con String(totalOrders) y comparar con el matcher toBe. Con eso, el test pasa y la sección exclusiva de administradores queda cubierta.

¿Qué herramientas y conceptos usaste en este test?

• Roles de usuario en pruebas: pasar superadmin al render para activar bloques condicionales del componente [0:14].
• handleValidateUserAdmin: la función que valida el rol y decide si Order Summary se monta [0:32].
• getSummaryOrders: utilidad que recibe el arreglo de órdenes y devuelve total, valor total y promedio de forma estructurada [1:25].
• mockOrders: arreglo simulado de órdenes que alimenta tanto al componente como a la utilidad en el ambiente de test [1:46].
• waitFor: helper asíncrono de React Testing Library para esperar render tras operaciones diferidas [1:21].
• getByTestId: query que busca un elemento por su atributo data-testid, útil cuando getByText devuelve múltiples coincidencias [2:38].
• data-testid: atributo que agregas al JSX para exponer un nodo único a las pruebas [3:10].
• textContent: propiedad del DOM que devuelve solo el texto del nodo, sin envoltura HTML [3:55].
• toBe vs toHaveTextContent: matchers de Jest. toBe compara igualdad estricta; aquí se usa tras convertir el número a string [4:11].

El reto que queda sobre la mesa: usa data-testid para testear los demás valores que retorna getSummaryOrders, como el total de ventas y el promedio. Comparte tu solución en los comentarios y nos vemos en la siguiente clase.