Passer au contenu principal

Présentation des tests

Qu'est-ce qui doit être testé ?​

Les applications Jutro suivent la philosophie de React, qui consiste à composer à partir de composants. Les interfaces utilisateur Jutro sont créées à partir de composants atomiques. Ces composants sont assemblés en pages. Un plan gère ensuite les pages.

Chaque élément de l'interface utilisateur est techniquement un composant, même une page est un composant. Ainsi, tester votre application revient à tester des composants.

Tests de bout en bout​

Les interactions utilisateur typiques impliquent l’utilisation de plusieurs composants. Les tests de bout en bout consistent à tester des groupes de composants, une page entière, voire plusieurs pages d’une application. Vous concevez des tests qui permettent de « cliquer », de « remplir des champs », de « glisser-déposer des éléments » et de réaliser d’autres actions qu’un utilisateur effectuerait.

L'approche de bout en bout est le moyen le plus fiable de vérifier la fonctionnalité de votre application et la plus facile à planifier. Les tests prennent en compte les principaux parcours des utilisateurs et vous avez ainsi toujours la certitude que l'utilisateur peut faire ce qu'il a besoin de faire dans votre application.

Visuel​

Les tests visuels dans Jutro reposent sur TestCafe. TestCafe crée une capture d'écran et la compare à une capture d'écran précédente. Cela vous permet de détecter toute modification accidentelle.

Pour des raisons de cohérence, vous exécutez les tests à l'aide de navigateurs spécifiques, généralement dans une image Docker.

Problèmes connus​

Il existe un problème connu avec testcafe qui utilise hummerhead et qui peut entraîner de façon aléatoire l’échec des modules micro front-end lors du rendu. Pour résoudre ce problème, effectuez une mise à niveau de testcafe vers la version 3.x.x, car les versions plus récentes n'utilisent pas hummerhead par défaut. Au cas où vous auriez besoin de l'utiliser, utilisez l'option --disableNativeAutomation.

Unité​

Certaines fonctionnalités sont plus théoriques que les interactions utilisateur. Les tests d'unité vous permettent de confirmer que même de très petites parties de votre application fonctionnent comme prévu. La rédaction de tests d'unité pour des applications Jutro vous permet généralement de tester les éléments suivants :

  • Vérifier si l'application s'affiche sans planter
  • Vérifier si un composant basé sur des métadonnées comporte des métadonnées valides
  • Vérifier si une fonction supposée raccourcir les descriptions longues renvoie réellement des chaînes d'une longueur spécifiée et ne bloque pas lorsque la description est plus courte que la longueur spécifiée
  • Vérifier si un rappel est appelé
  • Vérifier si un effet secondaire est déclenché le bon nombre de fois

Accessibilité​

Les tests d'accessibilité (a11y) mettent en évidence les problèmes que les personnes peuvent rencontrer lorsqu'elles utilisent votre application avec une forme de handicap visuel, auditif, de mobilité ou autre. Nous utilisons jest-axe pour tester automatiquement les principes de base a11y, mais nous vous recommandons vivement d'effectuer un suivi manuel. C'est la seule façon certaine de garantir le niveau d'accessibilité souhaité dans votre application.

Comprendre le workflow​

Pour rationaliser votre expérience de développement, nous vous recommandons le workflow suivant :

  • Rédigez un test de votre fonctionnalité de bout en bout.
  • Rédigez des tests d'unité pour définir tous les petits détails de chaque composant individuel.
  • Développez chaque composant pour créer la fonctionnalité globale jusqu'à ce que tous les tests soient réussis.
  • Vérifiez l'accessibilité (cela peut modifier l'apparence de votre application.).
  • Ajoutez des tests visuels pour obtenir l'apparence cible de votre composant, groupe de composants ou page.
  • Assurez-vous que vos tests sont exécutés avec succès dans TeamCity à chaque demande de récupération.