Les tests unitaires ont quelque chose de mystique ces jours-ci. Les gens le traitent comme si la couverture de test à 100% était un saint graal et comme si le test unitaire était la seule façon de développer un logiciel.
Ils manquent le point.
Les tests unitaires ne sont pas la solution. Le test est.
Maintenant, chaque fois que cette discussion survient, quelqu'un (souvent même moi) écrira la citation de Dijkstra: "Les tests de programme peuvent démontrer la présence de bugs, mais ne démontrent jamais leur absence." Dijkstra a raison: les tests ne suffisent pas pour prouver que le logiciel fonctionne comme prévu. Mais il est nécessaire : à un certain niveau, il doit être possible de démontrer que le logiciel fait ce que vous voulez.
Beaucoup de gens testent à la main. Même les enthousiastes du TDD effectueront des tests manuels, bien qu'ils ne l'admettent parfois pas. On n'y peut rien: avant de vous rendre dans la salle de conférence pour faire une démonstration de votre logiciel auprès de votre client / responsable / investisseurs / etc., vous le parcourrez à la main pour vous assurer qu'il fonctionnera correctement. Il n’ya rien de mal à cela, et en fait, il serait insensé de s’attendre à ce que tout se déroule sans heurts sans le parcourir manuellement, c’est-à-dire à le tester , même avec une couverture de 100% des tests unitaires et une confiance absolue dans vos tests. .
Mais les tests manuels, même s’ils sont nécessaires à la construction de logiciels, sont rarement suffisants . Pourquoi? Parce que les tests manuels sont fastidieux, prennent du temps et sont effectués par des humains. Et les humains sont notoirement mauvais pour effectuer des tâches fastidieuses et chronophages: ils évitent de les faire autant que possible, et souvent ils ne les font pas bien quand ils sont forcés de le faire.
Les machines , en revanche, sont excellentes pour effectuer des tâches fastidieuses et fastidieuses. C'est pour cela que les ordinateurs ont été inventés, après tout.
Les tests sont donc cruciaux et les tests automatisés sont le seul moyen judicieux de garantir que vos tests sont utilisés de manière cohérente. Et il est important de tester et de tester à nouveau le logiciel. Une autre réponse souligne l’importance des tests de régression . En raison de la complexité des systèmes logiciels, les modifications apparemment inoffensives apportées à une partie du système entraînent des modifications inattendues (c.-à-d. Des bogues) dans d'autres parties du système. Vous ne pouvez pas découvrir ces modifications inattendues sans une forme de test. Et si vous souhaitez disposer de données fiables sur vos tests, vous devez effectuer vos tests de manière systématique, ce qui signifie que vous devez disposer d'un système de test automatisé.
Qu'est-ce que tout cela a à voir avec les tests unitaires? De par leur nature, les tests unitaires sont exécutés par la machine et non par un humain. Par conséquent, de nombreuses personnes ont la fausse impression que les tests automatisés sont équivalents aux tests unitaires . Mais ce n'est pas vrai: les tests unitaires ne sont que de très petits tests automatisés.
Maintenant, quelle est la valeur des très petits tests automatisés? L'avantage est qu'ils testent les composants d'un système logiciel de manière isolée , ce qui permet un ciblage plus précis des tests et facilite le débogage . Mais les tests unitaires ne signifient pas intrinsèquement des tests de qualité supérieure . Cela conduit souvent à des tests de meilleure qualité, car il couvre les logiciels à un niveau de détail plus fin. Mais il est possible de tester complètement le comportement d'un système complet, et non de ses composants, tout en le testant de manière approfondie.
Mais même avec une couverture de 100% des tests unitaires, un système peut toujours ne pas être testé de manière approfondie. Parce que les composants individuels peuvent fonctionner parfaitement de manière isolée, ils échouent quand ils sont utilisés ensemble. Ainsi , les tests unitaires, bien que très utiles, ne suffisent pas pour garantir que le logiciel fonctionne comme prévu. En effet, de nombreux développeurs complètent les tests unitaires par des tests d'intégration automatisés, des tests fonctionnels automatisés et des tests manuels.
Si vous ne voyez pas l'intérêt des tests unitaires, la meilleure façon de commencer consiste peut-être à utiliser un type de test automatisé différent. Dans un environnement Web, l’utilisation d’un outil de test d’automatisation de navigateur tel que Selenium représente souvent un gain important pour un investissement relativement modeste. Une fois que vous avez plongé vos orteils dans l'eau, vous pourrez voir plus facilement à quel point les tests automatisés sont utiles. Et une fois que vous avez des tests automatisés, les tests unitaires ont beaucoup plus de sens, car ils offrent un délai d'exécution plus rapide que les gros tests d'intégration ou de bout en bout, car vous pouvez cibler les tests uniquement sur le composant sur lequel vous travaillez actuellement.
TL; DR: ne vous inquiétez pas pour le moment des tests unitaires . Ne vous inquiétez pas avant de tester votre logiciel.