Sommaire

Introduction

Dans le chapitre précédent, nous avons créé notre premier test unitaire développé avec la méthode TDD. Nous avons vérifié que notre composant fonctionnait bien de façon isolée. L’intérêt maintenant des tests d’intégration est de pouvoir garantir que l’ajout d’une nouvelle fonctionnalité ne fait pas régresser un domaine de notre application, ici notre projet siteWEB. Ces tests doivent aussi montrer que la nouvelle fonctionnalité interagit convenablement avec d’autres composants du projet comme la base de données, le système de fichiers ou encore le réseau. C’est une façon de dire "Est-ce que mon développement va fonctionner en production ?" La portée des tests d’intégration est donc plus large, mais aussi plus complexe à mettre en œuvre. Ces tests seront aussi plus longs à s’exécuter au sein de notre CI, car ils devront utiliser l’architecture dans laquelle s’inscrit l’application.

La mise en place des différentes couches de tests amène aussi des techniques de développement qui leur sont associées. Vous avez sûrement entendu des expressions comme IoC (Inversion of Control) ou Injection de dépendances. Ce sont des patrons de conception (Design Patterns) issus de la POO (programmation orientée objet). L’idée, pour faire simple, ...