Filosofía de las pruebas
Enfoque de Jutro en cuanto a las pruebas
En Jutro, le recomendamos que siga los principios de prueba recomendados por la biblioteca de pruebas. En resumen:
- Interactúe con la aplicación de la misma manera que sus usuarios.
- Pruebe la aplicación, no los detalles de su implementación.
- Utilice selectores basados en la accesibilidad, no en su conocimiento de la estructura de la aplicación.
El paquete @jutro/test también proporciona una serie de ayudantes útiles que facilitan el cumplimiento de los principios.
Lecturas complementarias
- Obtendrá más información sobre estos principios en la página de principios rectores de la biblioteca de pruebas.
- También le recomendamos que lea este artículo sobre por qué es no es bueno probar los detalles de implementación.
- No se olvide de la prioridad de las consultas.
- ¿Tiene miedo de cometer errores? Lea sobre algunos errores comunes para evitarlos.
Principios en la práctica
Interacción
Para interactuar con la aplicación de la misma manera que sus usuarios, seleccione elementos por atributos con los que el usuario interactúa, como rótulos o roles. Evite usar detalles de implementación, como ID y clases.
Seleccione un botón por texto.
Seleccione un botón por ID o posición en el árbol del DOM.
Para asegurarse de que su aplicación se traduzca correctamente, no debe interactuar con el texto de la pantalla, sino con una traducción de su archivo de mensajes. Para darle un ejemplo más realista:
import { getTranslation } from '@jutro/test';
import { messages } from '../MyComponent.messages';
const theButton = screen.getByRole('button', {
name: getTranslation(messages.awesomeButton),
});
Podría escribir una prueba de componentes de la siguiente manera:
import { render, screen } from '@jutro/test';
test('has correct welcome text', () => {
render(
<Welcome
firstName="John"
lastName="Doe"
/>
);
expect(
screen.getByRole('heading', { name: 'Welcome, John Doe' })
).toBeInTheDocument();
});
Si quiere más ejemplos, los hemos incluido en la sección Más ejemplos de interacción.
Aplicación ({#application})
Para probar su aplicación, no sus detalles de implementación, concéntrese en el resultado de la aplicación, en lugar de en los cambios de estado internos de la aplicación.
Compruebe si el botón de menú de perfil se muestra cuando el usuario inicia sesión en la aplicación (una prueba e2e).
Escriba una prueba unitaria que establezca Avatar.isAuthenticated en true y luego compruebe si Avatar.isDisplaying también se establece en true.
test('Verify that avatar exists in the application header after login', async (t) => {
await t
.expect(
queryByRole('button', {
name: getTranslation('User Profile'),
}).exists
)
.ok();
});
Accesibilidad
Para utilizar selectores basados en la accesibilidad, confíe en aria-role y otros atributos de ARIA. De esa manera, prueba lo que su aplicación renderiza para el usuario sin los detalles de cómo se renderiza allí.
Compruebe el HTML renderizado por un botón con el rol de "tab", cuyo atributo ARIA "selected" esté establecido en "true".
Seleccione el div que renderiza un botón de pestaña y verifique si tiene una clase que incluya la palabra "active".
Si se renderiza correctamente, el HTML para un conjunto de pestañas es:
<div role="tablist">
<button
role="tab"
aria-selected="false"
class="tab">
Pending claims
</button>
<button
role="tab"
aria-selected="true"
class="active tab">
Accepted claims
</button>
<button
role="tab"
aria-selected="false"
class="tab">
Rejected claims
</button>
</div>
En ese caso, la prueba puede seleccionar:
const activeTab = screen.getByRole('tab', { selected: true });
Para obtener más información, consulte Pruebas de accesibilidad.
Utilice los ID de componentes solo como último recurso
En la situación excepcional en la que el enfoque centrado en el usuario y la accesibilidad no sean suficientes, puede agregar el atributo data-testid. Por ejemplo, esto es útil cuando desea comprobar si una página se renderiza y desea seleccionar todo div para algo como una página de “Bienvenida” que no tenga ninguna funcionalidad específica.
Renderice el componente de la siguiente manera:
<div data-testid="home-page">{children}</div>
Y selecciónelo así:
const homePage = screen.getByTestId('home-page');
ID generados automáticamente
A cada componente de campo de una página se le agrega un número entero único al final del ID. Esto garantiza que cada ID sea único. El mismo número entero se agrega a los rótulos que hagan referencia al ID, para que no pierdan la conexión.
Por ejemplo, si especifica que el ID sea soup, el componente HTML tiene un ID como soup_0, soup_1, y así sucesivamente.
Para realizar pruebas usando el ID en un selector, tiene las siguientes opciones:
ID de prueba
En el HTML renderizado, cada campo obtiene un atributo data-testid adicional que es el mismo que el ID sin el número entero al final. Esto significa que el valor puede duplicarse para algunos componentes de la página.
Puede usar la propiedad testId para establecer un valor personalizado para el atributo data-testid en HTML.
{
"id": "soup",
"type": "field",
"component": "Input",
"componentProps": {
"testId": "chowder"
}
}
El HTML resultante:
<input
id="soup_0"
data-testid="chowder" />
Comodín
Use un comodín en el selector, como input[id*="soup"].
Desactivación de la generación automática de ID
Puede configurar su aplicación para que no genere ID únicos. En src/config/config.json, establezca:
"generateUniqueId": false,
De forma predeterminada, esta opción está establecida en true. Si la configura en false, quizás termine con ID duplicados en algunas páginas.