Test des services

Les services sont souvent les fichiers les plus faciles à tester. Voici quelques tests unitaires synchrones et asynchrones de l'écriture ValueService sans l'aide des utilitaires de test Angular.

Services avec dépendances

Les services dépendent souvent d'autres services qu'angular injecte dans le constructeur. Dans de nombreux cas, il est facile de créer et d'injecter ces dépendances manuellement tout en appelant le constructeur du service.

Voici MasterService un exemple simple :

MasterService délègue sa seule méthode getValue() dans l'injecté ValueService.

Voici plusieurs façons de le tester.

Le premier test crée un ValueService avec new et le transmet au constructeur MasterService.

Cependant, l'injection du service réel fonctionne rarement, car la plupart des services dépendants sont difficiles à créer et à contrôler.

Au lieu de cela, vous pouvez simuler la dépendance, utiliser une valeur factice ou créer un espion sur la méthode de service pertinente.

Préférez les espions, car ils constituent généralement le moyen le plus simple de simuler des services.

Ces techniques de test standard conviennent parfaitement aux services de test unitaire isolés.

Cependant, vous injectez presque toujours des services dans les classes d'applications utilisant l'injection de dépendance Angular et vous devez avoir des tests qui reflètent ce modèle d'utilisation. Les utilitaires de test Angular facilitent l'étude du comportement des services injectés.

Test de services avec le TestBed

Votre application s'appuie sur l'injection de dépendance Angular (DI) pour créer des services. Lorsqu'un service a un service dépendant, DI trouve ou crée ce service dépendant. Et si ce service dépendant a ses propres dépendances, DI les trouve ou les crée également.

En tant que consommateur de services, vous ne vous inquiétez de rien. Vous ne vous souciez pas de l'ordre des arguments du constructeur ni de la manière dont ils sont créés.

En tant que testeur de service, vous devez au moins penser au premier niveau de dépendances de service, mais vous pouvez laisser Angular DI créer le service et gérer l'ordre des arguments du constructeur lorsque vous utilisez l'utilitaire TestBed de test pour fournir et créer des services.

Angular Testbed

Le TestBed est le plus important des utilitaires de tests Angular. Le TestBed crée un module de test Angular construit dynamiquement qui émule un @NgModule Angular.

La méthode TestBed.configureTestingModule() utilise un objet de métadonnées pouvant posséder la plupart des propriétés d'un @NgModule.

Pour tester un service, vous définissez la propriété providers de métadonnées avec un tableau des services que vous allez tester ou simuler.

Puis injectez-le dans un test en appelant TestBed.get() avec la classe de service comme argument.
Ou à l'intérieur du beforeEach() si vous préférez injecter le service dans le cadre de votre configuration.
Lors du test d'un service avec une dépendance, fournissez le modèle dans le tableau providers. Dans l'exemple suivant, le mock est un objet espion.
Le test consomme cet espion de la même manière que précédemment.

Test sans beforeEach()

La plupart des suites de tests de ce guide appellent beforeEach() à définir les conditions préalables pour chaque it() test et s'appuient sur TestBed pour créer des classes et injecter des services.

Il existe une autre école de test qui n'appelle jamais beforeEach() et préfère créer des classes de manière explicite plutôt que d'utiliser le TestBed.

Voici comment vous pouvez réécrire l'un des tests MasterService dans ce style.

Commencez par insérer du code préparatoire réutilisable dans une fonction de configuration au lieu de beforeEach().

La fonction setup() renvoie un littéral d'objet avec les variables, telles que masterService celles qu'un test pourrait référencer. Vous ne définissez pas de variables semi-globales (par exemple, let masterService: MasterService) dans le corps du fichier describe().

Ensuite, chaque test appele setup() dans sa première ligne, avant de poursuivre avec les étapes qui manipulent le sujet du test et affirment les attentes.

Notez que le test utilise l'affectation de déstructuration pour extraire les variables de configuration dont il a besoin.
De nombreux développeurs estiment que cette approche est plus propre et plus explicite que le style beforeEach() traditionnel.

Bien que ce guide de test respecte le style traditionnel et que les schémas CLI par défaut génèrent des fichiers de test avec beforeEach() et TestBed, n'hésitez pas à adopter cette approche alternative dans vos propres projets.

Test du services HTTP

Les services de données qui effectuent des appels HTTP vers des serveurs distants injectent et déléguent HttpClient généralement au service Angular des appels XHR.

Vous pouvez tester un service de données avec un espion HttpClient injecté comme vous le feriez pour tout service comportant une dépendance.

Les méthodes HeroService reviennent Observables. Vous devez vous abonner à une observable pour :

• (a) la faire exécuter
• (b) affirmer que la méthode réussit ou échoue

La méthode subscribe() accepte les rappels success(next) et fail(error). Assurez-vous de fournir les deux rappels afin de capturer les erreurs. Négliger de le faire produit une erreur observable non capturée asynchrone que le lanceur de tests attribuera probablement à un test complètement différent.

HttpClientTestingModule

Les interactions étendues entre un service de données et le serveur HttpClient peuvent être complexes et difficiles à simuler avec des espions.

Le HttpClientTestingModule peut rendre ces scénarios de test plus gérables.