Skip to main content
Build the future with Agentforce at TDX in San Francisco or on Salesforce+ on March 5–6. Register now.

Premiers pas avec les tests

Objectifs de formation

Une fois cette unité terminée, vous pourrez :

  • Décrire l’utilité des tests unitaires et des tests de bout en bout ainsi que leurs différences
  • Expliquer le rôle des tests unitaires pour les composants Web Lightning

Prérequis

Dans ce module, vous développez des composants Web Lightning et des tests unitaires dans un projet Salesforce DX à l’aide de l’éditeur Visual Studio Code. Si vous débutez avec les composants Web Lightning, Salesforce DX ou l’utilisation de Visual Studio Code pour le développement Salesforce, nous vous recommandons de réaliser les projets Prise en main rapide : Salesforce DX, Prise en main rapide : Visual Studio Code pour le développement Salesforce et Prise en main rapide : composants Web Lightning avant de continuer.

L’importance des tests

« Tout bogue non détecté lors de la phase de conception sera dix fois plus long à détecter lors de la phase de codage et encore dix fois plus long lors de la phase de débogage. » 

—Dr Nikolai Bezroukov, The Art of Debugging

Recherche de bogues logiciels représentés par une loupe sur une coccinelle

Le débogage et les tests sont des processus liés, mais distincts dans le développement logiciel. Les tests permettent de trouver et de signaler les erreurs. Le débogage permet d’identifier la cause de ces erreurs et de les corriger. Selon Nikolai Bezroukov, il est toujours préférable de rechercher et de corriger les bogues le plus tôt possible.

Dans un monde idéal, les logiciels n’auraient aucun bogue. La réalité est bien différente : nous faisons des erreurs, les exigences sont mal comprises et les applications sont utilisées de manière inattendue. Les tests aident à repérer ces problèmes afin de pouvoir les résoudre. Plus vous trouvez des bogues tôt, moins ils seront « chers ». Chaque fois qu’un bogue persiste dans une nouvelle étape du développement (ou dans le pire des cas, de la production), davantage de personnes et de processus sont impliqués dans son identification et dans sa correction.

Il existe deux types de tests couramment exécutés pour les applications Salesforce : les tests unitaires et les tests de bout en bout. Leurs différences résident dans leur portée et leur objectif.

Tests unitaires

Les tests unitaires portent sur de petites fonctionnalités discrètes dans une application. Pour faciliter les tests unitaires, créez votre application à l’aide de petites unités pouvant être testées, au lieu d’écrire une unique et longue méthode ou classe Apex. En d’autres termes, vous devez modulariser le code en méthodes discrètes qui peuvent être testées indépendamment. De même, plutôt que d’écrire un seul composant Lightning volumineux pour une application, modularisez les fonctionnalités en composants plus petits qui peuvent être testés indépendamment. Des tests unitaires courts et rapides, faciles à exécuter, encouragent les développeurs à les écrire et à les exécuter dans le cadre de leur processus de développement et d’intégration continue. Ainsi, les bogues sont identifiés et corrigés le plus tôt possible. Veillez à consulter l’article sur le développement piloté par les tests (TDD) pour obtenir plus d’informations sur ce processus.

Tests de bout en bout

Les tests de bout en bout se concentrent sur une application entière ou un parcours utilisateur. Pour les applications Web, cela implique généralement des tests dans un navigateur afin de valider la manière dont le code et les composants d’une page fonctionnent conjointement dans un environnement de test, tel qu’une sandbox ou une organisation test.

Les tests de bout en bout ont tendance à prendre plus de temps que les tests unitaires, car ils couvrent chacun plus de fonctionnalités de l’application. Les tests de bout en bout sont également moins fiables que les tests unitaires en raison des incohérences aléatoires d’un environnement en direct, telles que la latence du réseau, la mise en cache, la dépendance à des systèmes tiers, les problèmes d’infrastructure, etc. Ces incohérences peuvent entraîner la réussite ou l’échec d’un test de manière aléatoire. C’est ce que l’on appelle un test « flaky ». Malgré ces inconvénients, les tests de bout en bout fournissent une validation précieuse et plus réaliste de l’application et de ses points d’intégration que les tests unitaires.

Comparaison des tests unitaires et des tests de bout en bout

Voyons comment les tests unitaires et les tests de bout en bout fonctionnent dans la pratique. À titre d’exemple, nous utiliserons le composant Web Lightning api-property du référentiel lwc-recipes, qui contient une collection d’exemples de code pour les composants Web Lightning sur la plate-forme Salesforce.

Le composant <c-api-property> est constitué des composants suivants : (1) <lightning-card>, (2) <lightning-input> et (3) <c-chart-bar>.

  1. Le composant <lightning-card> affiche le titre ApiProperty et contient les deux autres composants.
  2. Le composant <lightning-input> gère l’entrée utilisateur d’un nombre et diffuse des événements de changement de valeur.
  3. Le composant <c-chart-bar> restitue un graphique à barres en fonction de sa valeur en pourcentage.

Composant ApiProperty avec ses composants enfant mis en évidence

Chacun de ces trois composants possède ses propres API publique, état interne et comportement. Ils pourraient exécuter leurs propres tests unitaires pour valider leur fonctionnalité indépendamment des autres composants. De fait, les tests unitaires pour le composant <c-api-property> peuvent supposer que les composants <lightning-card>, <lightning-input> et <c-chart-bar> fonctionneront comme prévu ou pourront présenter des comportements fictifs pour simuler différents scénarios dans diverses conditions.

Dans cet exemple, un test de bout en bout charge le composant <c-api-property> dans une page de navigateur, saisit des valeurs de pourcentage dans le champ de saisie et procède à l’assertion du rendu du graphique à barres en conséquence. Il n’existe pas de données ou de comportements fictifs pour les tests de bout en bout : vous vérifiez la manière dont les trois composants fonctionnent conjointement comme s’ils étaient déployés auprès de vos utilisateurs.

Récapitulatif

Le tableau suivant est une comparaison générale des avantages et des inconvénients des tests unitaires et des tests de bout en bout. 


Tests unitaires
Tests de bout en bout
Les tests sont rapides
Oui
Non
Les tests sont fiables
Oui
Non
Les tests sont précis et permettent d’identifier les problèmes exacts
Oui
Non
Les tests couvrent de nombreuses fonctionnalités d’une application en une fois
Non
Oui
Les tests simulent un utilisateur réel
Non
Oui

Maintenant que vous en savez plus sur les différences entre les tests unitaires et les tests de bout en bout, passons à la pratique. La suite de ce module porte sur les tests unitaires des composants Web Lightning.

Ressources

Partagez vos commentaires sur Trailhead dans l'aide Salesforce.

Nous aimerions connaître votre expérience avec Trailhead. Vous pouvez désormais accéder au nouveau formulaire de commentaires à tout moment depuis le site d'aide Salesforce.

En savoir plus Continuer à partager vos commentaires