Passer au contenu principal

Philosophie de test

Approche Jutro des tests​

Chez Jutro, nous vous recommandons de suivre les principes de test préconisés par la bibliothèque de tests. En bref :

  • Interagir avec votre application de la même manière que vos utilisateurs
  • Tester votre application, et non vos détails d'implémentation
  • Utiliser des sélecteurs basés sur l'accessibilité, et non sur votre connaissance de la structure des applications

Le package @jutro/test fournit également un certain nombre d'assistants utiles qui simplifient la mise en œuvre de ces principes.

Lecture supplémentaire​

Mise en pratique des principes​

Interaction​

Pour interagir avec votre application de la même manière que vos utilisateurs, sélectionnez des éléments par attributs avec lesquels l'utilisateur interagit, comme des étiquettes ou un rôle. Évitez d'utiliser des détails d'implémentation, tels que des ID et des classes.

Do

Sélectionnez un bouton par texte.

Don't

Sélectionnez un bouton par ID ou positionnez-le dans l'arborescence DOM.

Pour vous assurer que votre application est correctement traduite, n'interagissez pas avec le texte à l'écran, mais avec une traduction provenant de votre fichier de messages. Voici un exemple plus parlant :

import { getTranslation } from '@jutro/test';
import { messages } from '../MyComponent.messages';

const theButton = screen.getByRole('button', {
  name: getTranslation(messages.awesomeButton),
});

Vous pouvez écrire un test de composant comme suit :

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 vous le souhaitez, vous pouvez consulter d'autres exemples dans la section Plus d'exemples d'interactions.

Application​

Pour tester votre application, et non vos détails d'implémentation, concentrez-vous sur le résultat dans l'application, plutôt que sur les changements d'état interne de l'application.

Do

Testez si le bouton de menu Profil s'affiche lorsque l'utilisateur est connecté à l'application (test de bout en bout).

Don't

Écrire un test d'unité qui définit Avatar.isAuthenticated sur true et vérifie ensuite si Avatar.isDisplaying est également défini sur 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();
});

Accessibilité​

Pour utiliser des sélecteurs basés sur l'accessibilité, utilisez aria-role et d'autres attributs ARIA. De cette façon, vous testez ce que votre application affiche pour l'utilisateur sans tenir compte des détails de la manière dont elle est affichée.

Do

Recherchez dans le code HTML affiché un bouton ayant le rôle « tab », dont l'attribut ARIA « selected » est défini sur « true ».

Don't

Sélectionnez div qui affiche un bouton d'onglet et vérifie s'il a une classe qui comporte le mot « active ».

S'il est affiché correctement, le code HTML d'un ensemble d'onglets est :

<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>

Dans ce cas, votre test peut sélectionner :

const activeTab = screen.getByRole('tab', { selected: true });

Pour en savoir plus, reportez-vous à la section Test d'accessibilité.

Utilisation d'ID de composant uniquement en dernier recours​

Si vous vous trouvez dans la rare situation où l'approche orientée utilisateur et l'accessibilité ne suffisent pas, vous pouvez ajouter l'attribut data-testid. Par exemple, il s'agit d'une bonne approche lorsque vous souhaitez vérifier si une page s'affiche et que vous souhaitez sélectionner div dans son ensemble pour un élément tel qu'une page de « bienvenue » qui n'a pas de fonctionnalité spécifique.

Affichez votre composant comme suit :

<div data-testid="home-page">{children}</div>

Et sélectionnez-le comme suit :

const homePage = screen.getByTestId('home-page');

ID générés automatiquement​

Chaque composant de champ sur une page reçoit un nombre entier unique ajouté à la fin de l'ID. Cela garantit que chaque ID est unique. Le même nombre entier est ajouté aux étiquettes qui font référence à l'ID, afin que le lien soit maintenu.

Par exemple, si vous indiquez que l'ID est soup, l'ID du composant HTML ressemble à soup_0, soup_1, etc.

Pour effectuer un test à l'aide de l'ID dans un sélecteur, vous disposez des options suivantes :

ID de test​

Dans le rendu HTML, chaque champ reçoit un attribut supplémentaire data-testid qui est identique à l'ID, sans le nombre entier à la fin. Cela signifie que la valeur peut être dupliquée pour certains composants de votre page.

Vous pouvez utiliser la propriété testId pour définir une valeur personnalisée pour l'attribut data-testid dans HTML.

{
  "id": "soup",
  "type": "field",
  "component": "Input",
  "componentProps": {
    "testId": "chowder"
  }
}

HTML qui en résulte :

<input
  id="soup_0"
  data-testid="chowder" />

Caractère générique​

Utilisez un caractère générique dans le sélecteur, par exemple input[id*="soup"].

Désactiver la génération automatique d'ID​

Vous pouvez paramétrer votre application pour qu'elle ne génère pas d'ID uniques. Dans src/config/config.json, définissez :

src/config/config.json
"generateUniqueId": false,

Par défaut, cette option est définie sur true. Si vous la définissez sur false, vous risquez d'avoir des ID en double sur certaines pages.