Tester son application

1. Qu’est-ce qu’un test ?

Les tests sont une composante essentielle du développement logiciel moderne. Ils garantissent non seulement la qualité et la fiabilité du code, mais permettent aussi de détecter les régressions, c’est-à-dire de s’assurer que chaque modification n’altère pas le comportement attendu de l’application, facilitant ainsi la maintenance à long terme.

Angular, grâce à son écosystème riche, fournit un ensemble d’outils et de bonnes pratiques pour implémenter plusieurs types de tests et il est parfois difficile de savoir quand, quoi et comment tester. Ce chapitre propose une approche pratique des tests dans Angular, en explorant à la fois les concepts fondamentaux et les outils à disposition.

Nous allons voir deux principaux types de tests : les tests unitaires (unit tests, ou UT) et les tests de bout en bout (end-to-end, ou e2e), dont voici les définitions :

1. Structure d’un test

Dans Angular, chaque fichier de test unitaire porte généralement l’extension ".spec.ts". Par convention, chaque composant, service ou autre entité Angular a son propre fichier de test associé ; d’ailleurs, par défaut, en utilisant la ligne de commande d’Angular pour générer un élément du framework, un fichier de test sera automatiquement créé (tant que vous ne spécifiez pas explicitement l’argument --skip-tests).

Voici un exemple de définition de test avec Jasmine :

describe('Filters', () => { 
  it('should return even numbers', () => { 
    const result = isEven(2); 
    expect(result).toBeTruthy() 
  }); 
}); 

Nous avons donc une suite de tests définie par la fonction describe(), ainsi qu’un test unique via it(). Ces deux fonctions prennent une chaîne de caractères, représentant l’identifiant, puis un callback qui sert d’exécution. Enfin, chaque test a pour but de créer une assertion via l’instruction expect(), basée sur une valeur précise, suivie par un comparateur comme toBe(), toBeTruthy(),toEqual(), etc., et c’est ce qui déterminera si le test passe ou non.

Globalement, chaque niveau a son importance : nous voulons une suite de tests relatifs à une fonctionnalité spécifique. Dans cette suite : un ou plusieurs tests pour assurer les différents cas d’exécution et aspects de la fonctionnalité, puis finalement, l’intérieur d’un test peut comporter autant d’assertions que nécessaire pour une bonne couverture du besoin.

À côté des tests, nous pouvons...

1. Vocabulaire

Dans le cadre des tests unitaires, plusieurs termes sont utilisés pour désigner les différents éléments qui nous aident à tester les fonctionnalités. De manière générale, comme nous souhaitons tester le plus unitairement possible, nous cherchons à nous isoler de toute logique externe aux éléments que nous testons. Cela nous conduit à créer des substituts pour remplacer le code externe, afin d’assurer des tests précis et indépendants. Ces substituts portent différents noms selon leur objectif et la façon dont ils sont construits : doubles, stubs, mocks, spies, fakes, etc. Voici quelques définitions clés :

De notre côté, nous allons généraliser cela et utiliser les termes mock et spy.

2. Créer des substituts

1. Tester un composant

Tester ces composants permet de garantir leur bon fonctionnement en s’assurant que la logique, mais aussi le rendu et les interactions entre l’utilisateur et le DOM sont conformes à nos attentes.

1. Introduction à Cypress

Une fois Cypress installé avec ses dépendances, vous pouvez relancer la commande pour démarrer l’outil. Lors de son exécution, une première application de gestion s’ouvre et vous demande si vous souhaitez utiliser un navigateur web ou Electron pour faire tourner votre application.

Nous choisirons le navigateur, ce qui ouvrira une nouvelle instance isolée et dédiée de celui-ci, avec une interface de gestion des tests.

Cette interface liste tous les tests disponibles dans votre projet, organisés par fichier. Vous devriez y voir un premier fichier de test par défaut.

En cliquant sur un fichier, vous déclencherez l’exécution du test. En temps réel, Cypress vous permet de l’observer appliquer les actions définies dans le test comme les clics, navigations et remplissages de champs de saisie, par exemple.

// fixtures/users.json 
[{ 
  "name": "Kevin", "id": 2 
}] 
 
// test.cy.ts 
cy.fixture('users').then(data=> {...}) 

1. Tests unitaires

Il est préférable d’écrire les tests au fur et à mesure de la création du projet, voire d’adopter une approche de développement par le test (Test-Driven Development ou TDD). Cependant, dans notre cas, puisque le projet est déjà développé, nous allons créer l’ensemble des tests d’un coup.

Pour organiser les tests, il est recommandé de les placer à proximité des éléments qu’ils valident. Une autre approche consiste à séparer le code des tests dans des dossiers distincts. Nous opterons pour cette seconde approche en créant un dossier src/tests/. À l’intérieur, les tests seront répartis en sous-dossiers en fonction des types d’éléments Angular : composants, services, pipes, etc.

Contrairement aux tests E2E ou au développement, où l’organisation suit généralement une logique métier, les tests unitaires sont conçus pour isoler et valider des éléments spécifiques. Il n’est donc pas nécessaire d’adopter une structure basée sur les domaines métier.

Nous allons survoler plusieurs types d’éléments de notre projet à tester. Bien que nous ne détaillerons pas chaque cas de test un par un, vous trouverez une grande série des tests disponibles dans le code source en ligne sur GitHub.