Les tests sont incontournables dans la vie quotidienne du développeur. Ils peuvent être de nature diverse et se situer à différents niveaux de l’application. Les plus simples, que tout développeur réalise, sont exécutés manuellement ou à l’aide d’un débuggeur, après avoir codé une partie de l’application. Nous pouvons les définir comme des « tests d’intégration » manuels.
Ces tests prennent une grande partie du temps de développement car le développeur est obligé d’exécuter l’interface graphique (vos pages web), d’effectuer une série d’actions sur cette interface (clic sur un bouton par exemple, passage d’une page à l’autre, enregistrement d’un formulaire, etc.) et de vérifier le résultat de cette action. Cela permet de tester les composants et des classes interagissant ensemble pour produire un résultat final. Cependant, à chaque modification du code nous sommes obligés de recommencer les tests car nous n’avons aucune garantie de n’avoir pas cassé une autre fonctionnalité ailleurs dans l’application. Si le test ne réussit pas, tous les composants et les classes sont en échec solidairement et il est parfois difficile de trouver la vraie source du problème. Le test d’intégration signifie que nous testons deux modules d’application ou plus comme un groupe. En outre, il n’est pas possible de les enregistrer et de les exécuter d’une manière automatique. Ceci nous amène à la réflexion concernant les « tests unitaires ».
Thomas Jaskula