Tests unitaires

1. Classe TypeScript

Afin de tester un composant Angular, une librairie appelée @angular/core/testing est utilisée. Dans cette librairie, la classe TestBed va permettre de définir un environnement approprié pour le test du composant.

La méthode TestBed.configureTestingModule( { } ) est comparable dans sa syntaxe au décorateur @NgModule() du fichier app.module.ts. Elle prend en paramètre un objet composé des attributs imports, declarations, providers et schemas.

TestBed.configureTestingModule( { 
        imports: [ ], 
        declarations: [ ], 
        providers: [ ], 
        schemas: [ ] 
}).compileComponents(); 

Le module de test va ainsi contenir tous les objets nécessaires au composant à tester.

ng generate component composants/C17 

La première chose à tester est de savoir si le composant a réussi à s’instancier.

TestBed permet la création d’un composant grâce à la méthode createComponent(unComposant).

maVariable = TestBed.createComponent(monComposant); 

Le test portera sur l’instance de la variable maVariable. Il suffit de vérifier si elle est à vrai.

Puisque l’ensemble des tests portera sur le composant créé, il est très fortement recommandé de mettre toutes les opérations de création du composant dans la méthode beforeEach().

// C:\JavaScriptEtAngular\Angular\monProjetAngular\src\app\ 
composants\c17.component.spec.ts 
import {ComponentFixture, TestBed} from '@angular/core/testing'; 
import {C17Component} from './c17.component'; 
 
describe('Le composant C17', () => { 
 let composant: C17Component; 
 let fixture: ComponentFixture<C17Component>; 
 
 beforeEach(() => { 
     // Le composant est configuré et compilé 
     TestBed.configureTestingModule({ 
       imports: [ ], 
       declarations: [C17Component], 
       providers: [ ], 
       schemas: [ ] 
     }).compileComponents(); 
     // Le composant est créé 
     fixture = TestBed.createComponent(C17Component); 
     // L'instance du composant est dans une variable 
     composant = fixture.componentInstance; 
   } 
 ); 
 fit('doit être créé', () => { 
   // La variable est à vrai si le composant a bien été crée 
   expect(composant).toBeTruthy(); 
 }); 
}); 

Exécution d’un test sur un composant

2. Gabarit

Tester les méthodes et l’instanciation d’un composant d’une classe TypeScript, c’est bien, mais on ne teste que la moitié du composant. Pour rappel, un composant est une classe TypeScript, un gabarit HTML et une feuille de style.

@angular/core/testing possède une interface debugElement qui permet d’interagir avec l’ensemble des éléments HTML du gabarit. Celle-ci peut récupérer un élément par son id, sa classe CSS ou sa balise.

Pour récupérer un élément HTML par sa balise :

unElementHTML = fixture.nativeElement.querySelector('balise'); 

Pour récupérer un élément HTML par sa classe CSS :

unElementHTML = fixture.nativeElement.querySelector('.css'); 

Pour récupérer un élément HTML par son id :

unElementHTML = fixture.nativeElement.querySelector('#id'); 

Pour interagir avec le gabarit, il faut rajouter :

Supposons un gabarit HTML :

<!-- C:\JavaScriptEtAngular\Angular\monProjetAngular\src\app\ 
composants\c17\c17.component.html --> 
<div> 
 <p>Un paragraphe</p> 
 <span id="uneSpan">Une span avec un id</span> 
 <span class="uneClasseCSS">Une span avec du CSS</span> 
 <span class="uneClasseCSS">Une autre</span> 
</div> 

Le tester en utilisant les trois récupérations possibles serait :

// C:\JavaScriptEtAngular\Angular\monProjetAngular\src\app\ 
composants\c17\c17.comonent.spec.ts 
import { ComponentFixture, TestBed } from '@angular/core/testing'; 
 
import { C17Component } from './c17.component'; 
import { DebugElement } from '@angular/core'; 
 
describe('Le composant C17 : Lapis', () => { 
 let component: C17Component; 
 let fixture: ComponentFixture<C17Component>; 
 let debugElement: DebugElement; 
 
 beforeEach(() => { 
   TestBed.configureTestingModule({ 
     imports: [], 
     declarations: [C17Component], 
     providers: [], 
     schemas: [] 
   }).compileComponents(); ...

1. Énoncé

À partir de l’application PokemonManager développée dans les chapitres précédents, instaurez un minimum de couverture de code de 80 % sur les quatre éléments du rapport.

Faites en sorte d’atteindre une couverture de code de 80 %.

2. Correction

Pour l’instant, la commande ng test --code-coverage --watch=false ne remplit pas toutes les conditions de validité.

Couverture de code initiale

Bien entendu, ces chiffres peuvent être différents pour vous.

Le service pokemons.service.ts est la classe la plus facile à tester puisqu’il suffit de vérifier que les trois méthodes sont bien implémentées. Il est inutile de vérifier le retour de l’appel asynchrone vers l’API puisqu’un test unitaire ne doit pas dépendre d’une autre classe. Ici, le test doit être concluant, que l’API fonctionne ou non.

// C:\JavaScriptEtAngular\Angular\PokemonManager\src\app\ 
services\pokemons.service.spec.ts  
import { TestBed, inject } from '@angular/core/testing'; 
 
import { PokemonsService } from './pokemons.service'; 
import { HttpClientTestingModule } from '@angular/common/ 
http/testing'; 
 
describe('PokemonsService', () => { 
 let service: PokemonsService; 
 
 beforeEach(() => { 
   TestBed.configureTestingModule({ 
     imports: [HttpClientTestingModule] 
   }); 
   service = TestBed.get(PokemonsService); 
 }); 
 
 it('doit être créé', () => { 
   expect(service).toBeTruthy();  
 }); 
 
 it('doit implémenter trois méthodes', () => { 
   expect(service.getGenerations()).not.toBeUndefined(); 
   expect(service.getPokemons()).not.toBeUndefined(); 
   expect(service.getPokemon('test')).not.toBeUndefined();   }); 
}); 

Le formulaire de recherche est une simple classe TypeScript contenant un constructeur et un setter. Tester cette classe est relativement aisé.

Le testeur va utiliser le constructeur, utiliser...