L'intégration Continue
L'importance des tests
Au coeur de l'intégration continue
Lorsque l'on fait le choix de mettre en place un environnement d'intégration continue, il est indispensable de prévoir la mise en place de tests. Sans ceux-ci, l'intérêt d'un tel environnement s'en retrouve sévèrement limité (concrètement: vérifier que le code compile).
L'idéal est de développer en mode "test-driven", qui consiste à écrire les tests avant les développements. On réalise ainsi une véritable projection des objectifs à atteindre en terme d'implémentation, de fonctionnalités, de performances, d'intégration, etc.
Les tests de type "White-box"
Les tests appelés "White-box" (ou boîte blanche) sont ceux concernant la structure interne d'une application. La réalisation de ces tests relèvent directement de la compétence des programmeurs, puisqu'il s'agit de tester leurs implémentations. Il est possible de donner la responsabilité du code et des tests à 2 ressources différentes, mais beaucoup de développeurs déconseillent cette approche. C'est jugé contre-productif car l'appropriation du code est coûteuse, mais le testeur dispose d'un recul idéal. Cela peut donc se justifier selon le niveau de fiabilité recherché.
Les tests unitaires
Les tests unitaires sont ceux ayant la granularité la plus faible. Ils se restreignent le plus souvent à tester le bon fonctionnement d'une d'une méthode ou d'une classe. Quasiment tous les langages disposent de leurs tests unitaires (JUnit, PHPUnit, CUnit, etc.). Le plus souvent, ces tests sont réalisés à base d'assertions ("S'assurer que"). Une bonne pratique est de tester les cas particulier, qui sont généralement ceux qui posent problème. Ainsi, pour une fonction de division, on testera le retour d'une division par zéro, par un nombre négatif, etc.
Les tests d'intégration
Les tests d'intégration se placent au niveau modulaire de l'application. Chaque module est spécifié par ses entrées-sorties, qui doivent concorder pour qu'il puisse communiquer. Les tests d'intégration vont donc vérifier que le lien entre les modules est cohérent et qu'il conserve l'application dans un état stable. Les tests d'intégration permettent souvent de constater des erreurs subtiles, comme des problèmes de typage, d'encodage, de volumétrie ou des oublis lors de l'étape de spécification.
Les tests de performance
Les tests de performance d'une application peuvent aller du plus simple (calcul du temps d'éxecution d'une application) au plus complexe (en utilisant un logiciel de profiling comme JMeter). Les outils de profiling peuvent être directement intégrés au cycle d'intégration continue. Ainsi il est possible de repérer les goulots d'étranglement, lorsque les performances ne sont pas jugées satisfaisantes. L'erreur classique est de vouloir optimiser des bouts de code n'ayant pas d'impact signification sur les performances de l'application. Coûteux et inutile.
Les tests de qualité
Les tests de qualités sont réalisés à l'aide d'outils dédiés (comme CheckStyle), pouvant eux aussi être intégrés à l'environnement d'intégration continue. Il est ainsi possible de repérer les duplications de code (généricité), la documentation, les bonnes pratiques de développement, etc. Ces données sont le plus souvent accessibles au travers de rapports, disponibles sur le panel du serveur d'intégration. A noter l'existence de l'excellent outil Sonar (à déployer sur un serveur d'application), une plateforme qui agrège plusieurs outils de qualité.
Les tests de type "Black-box"
Les tests "Black-box" consistent à considérer l'application développée comme une boite noire, dont on ne se soucie pas de la structure interne, afin d'en vérifier son comportement d'un point de vue externe. On testera donc uniquement les entrées-sorties de l'application, et sa stabilité.
Les tests fonctionnels
Comme leur nom l'indique, il s'agit ici de tester les fonctionnalités de l'application. Les fonctionnalités sont des éléments mesurables, quantifiables. C'est au travers de des dernières qu'on détermine le bon respect du cahier des charges ou pas. C'est pourquoi ces tests, nécéssitant le plus souvent des manipulations "end-user", sont étroitements liées au cahier de recette de l'application.
Les tests de montée en charge
Toute application est concue pour être en activité, en continu (sous forme de service) ou ponctuellement. Le cahier des charges précise souvent des conditions de stabilité et de performances à des niveaux de volumétries donnés. Sur des projets de taille conséquence, ces tests sont généralement réalisés sur un serveur de pré-production (identique au serveur de production), afin de ne pas compromettre la stabilité du serveur d'intégration ou du serveur de test.