Tests unitaires
- Vient du fait qu’une partie du code est appelé Unit
- Ce type de test va vérifier un module du code
et qu’il fonctionne de manière indépendante
du reste - Respecte aussi des spécifications
fonctionnelles - Ils peuvent être manuels ou automatisés par
des logiciels - Chaque programmeur doit obligatoirement
faire ses tests unitaires. - Donne une garantie de qualité lors du
développement - Ils permettent de préparer les tests
d’intégration et de non-régression. - Indispensable pour l’intégration continue et à
l’agilité.
Pour réaliser des tests unitaires il nous
faut :
–des jeux de données (fictives, de
production, ancien jeux de tests)
–des ressources (documents de
spécifications, scénarios, fiches de
tests, tests précédents)
–Une démarche
Les différentes démarches :
*Analyse dynamique structurelle
*Analyse dynamique fonctionnelle
*Analyse statique
*Boite noire
*Boite blanche
- Analyse Dynamique Structurelle
- Consiste à vérifier la structure du code ainsi que les
variables - On parcours tous les nœuds, les arcs, et chemins du
programme - On peut vérifier ainsi si un test If Then Else n’est pas utilisé
- Analyse Dynamique Fonctionnelle
- Consiste à vérifier le service rendu (la fonction) mais pas
comment il est rendu - On valide les règles de gestion
- La difficulté réside au choix des données de tests pour
obtenir les résultats attendus
- Analyse Statique
- Cette notion d’analyse permet d’obtenir des informations sur le
comportement du programme sans réellement l’exécuter - On utilise des méthodes comme les nombres cyclomatiques, la
mesure de Halstead …
- Boite Noire
- On vérifie que les sorties obtenues sont celles prévues pour les
données entrées - Le fonctionnement interne n’est pas accessible
- Souvent utilisé pour les tests de non régression, de robustesse et de
charge
- Boite Blanche
- On valide le code et on vérifie qu’il n’y a pas de problème
- On ne teste pas le fonctionnel mais tous les chemins possibles du
programme
Couverture de code
! La couverture de code est une métrique qui peut vous
aider à comprendre quelle quantité de votre code source
est testée.
! C’est une métrique très utile qui peut vous aider à évaluer
la qualité de votre suite de tests et par conséquence la
qualité de votre code.
! Les outils de couverture de code utiliseront un ou
plusieurs critères pour déterminer comment votre code a
été testé ou pas, lors de l’exécution de votre suite de tests.
– JACOCO
– JCov
– OpenClover
– Cobertura
– Serenity
Comment la couverture de
code est-elle calculée ?
! Ces métriques sont généralement représentées par le nombre
d’éléments réellement testés, les éléments trouvés dans votre
code et un pourcentage de couverture (éléments testés /
éléments trouvés)
Les mesures courantes des rapports de couverture incluent :
– Couverture de fonction :
combien de fonctions définies ont été
appelées.
– Couverture des instructions :
combien d’instructions du
programme ont été exécutées.
– Couverture des branches :
combien de branches des structures de
contrôle (instructions if par exemple) ont été exécutées.
– Couverture des conditions :
combien de sous-expressions
booléennes ont été testées pour une valeur vraie et une valeur
fausse.
– Couverture des lignes :
combien de lignes de code source ont été
testées.
Etape préliminaire
Transformer le programme en un graphe de flux de contrôle:
Couverture des
instructions
! chaque instruction est
exécutée au moins une
fois
Couverture des branches
chaque branche (vrai/faux)
d’une décision (test ou
condition de boucle) est
parcourue au moins une
fois
Couverture des conditions
! Dans le cas où une décision
comprend plusieurs
conditions, une condition
peut en cacher une autre
! S’assurer que chaque
condition est évaluée au
moins une fois
! S’assurer que chaque
combinaison possible de
conditions est évaluée au
moins une fois
Comment définir l’ensemble
minimal des cas de tests?
arcs - # sommets + 2
Calculer le nombre de circuits indépendants (=base)
= nombre de tests à définir pour avoir la couverture complète
Toute exécution du programme est une combinaison de ceux-là
Nombre de cas de tests à trouver =
Choisir un cas de test qui représente une exécution quelconque
En ajouter un avec au moins un nouvel arc (non encore parcouru
par un cas de test précédent
Déterminer les Résultats
attendus
! Pour chaque cas de test, déterminer le résultat
attendu à partir de la spécification
– Exemple:
! Spec=”Lire deux entiers, afficher combien parmi eux sont
positifs.”
– Résultats:
! 1. 2 est affiché
! 2. 1 est affiché
! 3. 0 est affiché
Exécuter les tests
! Exécuter le test et comparer le résultat obtenu avec le résultat
attendu
Stratégies de développement
des tests unitaires
- Garder des tests propres
- Le code de tests est aussi important que le code de votre
application. - Rendre le code lisible est aussi important que le rendre
exécutable.
- Le code de tests est aussi important que le code de votre
- Une seule assertion par test
– Les tests conduisent à une seule conclusion qui se révèle
rapide et facile à comprendre. - Un seul concept par test
– Minimiser le nombre d’assertions par concept et de tester un
seul concept par fonction de test.
- Les tests propres suivent cinq autres règles qui
forment l’acronyme F.I.R.S.T
- Fast (rapide). Les tests doivent être rapides.
- Independent (indépendant). Les tests ne doivent pas dépendre
les uns des autres. - Repeatable (reproductible). Les tests doivent pouvoir être
reproduits dans n’importe quel environnement. - Self-Validating (auto validant). Les tests doivent avoir un
résultat binaire : ils réussissent ou ils échouent. - Timely (au moment opportun). Les tests doivent être écrits au
moment opportun.
Stratégies de développement
des tests unitaires
! Right-BICEP Guidelines
- Right : Are the results right?
- Les résultats sont-ils bons ?
- B : Are all the boundary conditions CORRECT?
- Toutes les conditions aux limites sont-elles correctes ?
- I : Can you check the inverse relationship?
- Pouvez-vous vérifier les relations inverses ?
- C : Can you cross-check results using other means?
- Pouvez-vous recouper les résultats par d’autres moyens
(Validation croisée)? - E : Can you force error conditions to happen?
- Pouvez-vous forcer les conditions d’erreur à se produire ?
- P : Are performance characteristics within bounds?
- Les caractéristiques de performance sont-elles dans les limites ?
Stratégies de développement
des tests unitaires
! RIGHT
- Dépend des exigences
- Écrivez d’abord le code de test en fonction de ce que le code est censé faire
- Par exemple, pour tester si une valeur renvoyée par la fonction plusGrand() est
correcte ou non, nous pouvons tester de grandes quantités de données lues à partir
d’un fichier.
Stratégies de développement
des tests unitaires
! Boundary check - CORRECT
- Conformance - Verify a value conforms to an expected format
- la valeur est-elle conforme au format attendu ?
- Order - Verify the set of values ordered
- l’ensemble des valeurs est ordonnée ou non ordonnée selon le cas?
- Range - Verify a value within the reasonable minimum and maximum values
- la valeur est entre les valeurs minimales et maximales raisonnables?
- Reference - Verify the code that reference something external that isn’t under direct
control of the code itself - le code fait-il référence à un élément extérieur qui n’est pas sous le contrôle direct du code ?
- Existence - Verify whether a value exists
- la valeur existe-t-elle (est-elle nulle, vide, présente dans un ensemble, etc.) ?
- Cardinality - Verify there’re exactly enough values
- Y a-t-il exactement assez de valeurs ?
- Time - Verify everything is happening in order, at the right time, or in time.
- Est-ce que tout se passe dans l’ordre? Au bon moment? Dans la durée?
Stratégies de développement
des tests unitaires
! Inverse Check
* Vérifier une méthode en appliquant son inverse logique
* Par exemple, vérifiez une méthode qui calcule une racine carrée en
élevant un nombre au carré et vérifiez qu’elle est assez proche du nombre
d’origine
! Cross-check
* S’il y a plus d’une façon de calculer une valeur, le résultat peut être
recoupé par une méthode différente.
* Cette technique est applicable au système de test lorsqu’il existe un
moyen éprouvé et connu qui est n’est pas flexible ou trop lent.
! Force error conditions
* Des objets fictifs (Mock objects) peuvent être utilisés pour simuler des erreurs du monde réel telles que la coupure de la connexion réseau, la
charge du système et un disque avec un espace libre limité.
! Performance characteristics
* S’assurer que le code atteint les objectifs de performance
* Réalisez le test de temps réponse avec des performances limitées
* Par exemple, un système d’indexation de pages Web avec leur URL
fonctionne bien pour une petite liste d’URL, il est nécessaire de tester s’il
fonctionne toujours bien pour une grande liste d’URL
