101 Unit Test

21-02-2022

1 minute read

Pourquoi tester ? tester c’est douter !

tests unitaires : test bas niveau pour tester une seule unité | exécuté en ms
tests d’intégration : interaction des services (BDD, Api)
tests fonctionnels : interagir avec un service selon les exigences métiers
tests de bout en bout (test automatiques) : reproduire le comportement d’un utilisateur final dans un environnement de test | à automatisé | plusieurs minutes
tests d’acceptation : test de PO
tests de performance : vérifier le comportement en cas de surcharge
tests de sécurité : OWASP

une approche qui consiste à écrire les tests avant la logique métier.

TDD image

mike cohn’s test pyramid

test pyramid

-Tester plusieurs scénarios d’un même fonctionnement. -Factoriser le code. -Assurer la non regression.

ça demande une certaine rigueur.
ça prend du temps (on oublie de les estimer)
l’architecture du code ne facilite pas l’écriture des tests (Interface, static )
Il faut les maintenir à jour.

une indication quantifiable sur le degré de test. ça aide a créer plus de scénarios de tests.

== Une bonne couverture ne veut pas dire que le code est bien testé == mais ça n’empêche pas de l’avoir dans les conditions de PR

simuler le comportement d’un objet.

pouvoir définir un résultat attendu pour un objet (pas de contrainte BDD , API …)

Nlayer image

80% couverture de code.
user interface piloter par le code | architecture.
MsTest | Moq | Fixiture
exemple : BatchReleaseExtTests , APReleaseProcessYearClosingTests , POOrderEntryExtTests