Supposons que vous vouliez tester manuellement votre application à chaque fois que vous la déployiez. Comment vous y prendriez-vous?
Eh bien, pour commencer, vous pourriez faire une liste de toutes les choses que vous voulez tester afin de ne pas oublier de tester quelque chose plus tard. Ensuite, vous écririez probablement les étapes de chaque test pour vous assurer de les faire de la même manière à chaque fois. Si vous ne vous êtes pas assuré que le processus de test que vous avez utilisé était cohérent, vos résultats ne seraient pas cohérents.
Donc, maintenant que vous avez la liste des tests que vous devez effectuer, vous devez ouvrir votre navigateur, lire les premières étapes du test, les exécuter et noter le résultat. Vous répéteriez ce processus pour chaque test de votre liste.
Le nombre de tests que vous effectuez continuerait à augmenter à mesure que votre application se développe et que vous trouvez de nouveaux bogues. Vous seriez, bien sûr, limité à effectuer ces tests à la vitesse humaine, ce qui les rend plutôt lents.
L'ironie ici est qu'en parcourant mécaniquement une liste d'opérations, vous calculez. Vous le faites simplement plus lentement que, disons, un ordinateur.
C'est, entre autres bonnes raisons, pourquoi nous écrivons des tests unitaires: ils laissent l'ordinateur faire l'informatique pour que vous n'ayez pas à le faire.
Je peux exécuter une suite de tests unitaires complète assez rapidement pour l'utiliser fréquemment pendant le développement, pas seulement une fois par semaine avant le déploiement. Cela me permet de détecter les erreurs plus rapidement, ce qui me fait gagner du temps et de l'argent.
Je peux même écrire des tests qui prédisent le comportement du système, puis écrire ce comportement (que je sais déjà correct parce que je viens de le tester), un processus appelé Test Driven Development.