En général
Quand avez-vous suffisamment de tests automatiques pour avoir confiance dans votre pipeline d'intégration continue?
La réponse devient probablement claire si vous pensez à quoi vous voulez avoir confiance. En fin de compte, il correspond à 1-1; chaque test vous donne confiance en la seule chose qu'il teste:
- Les tests unitaires vous donnent l'assurance qu'une classe (ou un module) fait ce pour quoi elle est testée.
- Les tests d'intégration vous donnent l'assurance que plusieurs unités fonctionnent ensemble de la manière testée.
- Les tests de bout en bout vous donnent l'assurance que l'application entière fait une certaine chose, de la manière décrite dans le test.
D'après la façon dont vous avez formulé votre question, vous pensez probablement dans un sens commercial global en ce moment, par exemple:
Je veux être sûr que mon application peut faire X .
Vous écrivez donc un test de bout en bout qui essaie de faire X et vérifie s'il le fait correctement.
Plus concret
Tout cela est très autoréférentiel, mais c'est parce que c'est à cela que cela revient. Il n'y a tout simplement pas plus.
Par exemple, imaginez que vous écrivez une application pour créer des recettes de cuisine. Une caractéristique est que, si vous ajoutez différentes quantités de plusieurs sortes de fromages, cela vous donne la température et le temps corrects pour qu'ils fondent tous.
Vous pouvez donc rédiger un test unitaire pour votre CheeseMeltCalculator
, où vous lui donnez 100 g de Gouda et 200 g d'Emmental, puis vous vérifiez que la température et le temps sont corrects. Cela signifie que vous pouvez maintenant être sûr que cela CheeseMeltCalculator
fonctionne pour 100g de Gouda et 200g de fromage. Maintenant, si vous répétez ce test avec 300 g de Gouda au lieu de 200 g, vous pouvez être assez sûr qu'il fonctionne correctement pour différentes valeurs. Vous pouvez ajouter des tests pour 0
, -1
et int.MaxValue
g de Gouda à être sûr que le code ne se déclenche pas (ou des voyages correctement comme prévu) pour l' entrée bizarre.
Vous pouvez écrire un test d'intégration pour vérifier qu'il CheeseMeltCalculator
est correctement intégré dans l'ensemble du processus de calcul de la température et du temps des aliments. Si cela ne fonctionne pas, mais que les CheeseMeltCalculator
tests ci-dessus sont corrects, vous pouvez être sûr que le bogue se trouve dans d'autres calculatrices ou dans la façon dont les données de différentes calculatrices sont combinées.
Et enfin, vous pouvez écrire un test de bout en bout pour créer une recette entière, et l'une des choses que vous vérifiez est la température et le temps du résultat. Si les 2 niveaux de tests précédents sont corrects, mais que cela se passe mal, vous pouvez à nouveau être sûr que ces pièces sont correctes et l'erreur concerne la façon dont le calcul de la température est intégré dans l'application. Par exemple, l'entrée utilisateur n'est peut-être pas transférée correctement.
Et enfin , si tous ces tests sont bons, alors vous pouvez être sûr que " si vous ajoutez différentes quantités de plusieurs sortes de fromages, cela vous donne la bonne température et le temps pour qu'ils fondent tous "
Longue histoire courte
Le fait est que vous ne pouvez pas avoir de test "ça fonctionne correctement". Vous ne pouvez tester que "Si je fais X, Y arrive".
Cependant, c'est exactement ce qui devrait figurer dans les spécifications techniques du projet. Une déclaration comme « si vous ajoutez différentes quantités de plusieurs sortes de fromages différents, cela vous donne la température et le temps corrects pour qu'ils fondent tous » non seulement donne au client des attentes claires quant à ce que le produit fini fera, mais peut également être retourné en tests automatisés.
information additionnelle
L'utilisateur Richard a ajouté ces informations dans une modification:
Martin Fowler a un très joli résumé sur son site internet sur les stratégies les plus courantes: https://martinfowler.com/articles/microservice-testing/
Je ne veux pas supprimer cela, mais je veux dire ceci: Par rapport à cette réponse, ce n'est pas un "résumé", mais plutôt une explication beaucoup plus approfondie, avec de jolis graphismes et tout.
Mon conseil serait: si tout vous semble logique après avoir lu ma réponse, vous avez terminé. Si les choses ne semblent toujours pas claires, réservez un peu de temps et lisez l'article lié.