Tests unitaires

Question 1

Tests unitaires

Answer 1

• 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é.

Question 2

Pour réaliser des tests unitaires il nous
faut :

Answer 2

–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

Question 3

Les différentes démarches :

Answer 3

*Analyse dynamique structurelle
*Analyse dynamique fonctionnelle
*Analyse statique
*Boite noire
*Boite blanche

Question 4

• Analyse Dynamique Structurelle

Answer 4

• 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é

Question 5

• Analyse Dynamique Fonctionnelle

Answer 5

• 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

Question 6

• Analyse Statique

Answer 6

• 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 …

Question 7

• Boite Noire

Answer 7

• 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

Question 8

• Boite Blanche

Answer 8

• 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

Question 9

Couverture de code

Answer 9

! 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

Question 10

Comment la couverture de
code est-elle calculée ?

Answer 10

! 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)

Question 11

Les mesures courantes des rapports de couverture incluent :

Answer 11

– 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.

Question 12

Etape préliminaire

Answer 12

Transformer le programme en un graphe de flux de contrôle:

Question 13

Couverture des
instructions

Answer 13

! chaque instruction est
exécutée au moins une
fois

Question 14

Couverture des branches

Answer 14

chaque branche (vrai/faux)
d’une décision (test ou
condition de boucle) est
parcourue au moins une
fois

Question 15

Couverture des conditions

Answer 15

! 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

Question 16

Comment définir l’ensemble
minimal des cas de tests?

Answer 16

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

Question 17

Déterminer les Résultats
attendus

Answer 17

! 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é

Question 18

Exécuter les tests

Answer 18

! Exécuter le test et comparer le résultat obtenu avec le résultat
attendu

Question 19

Stratégies de développement
des tests unitaires

Answer 19

• 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.
• 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.

Question 20

• Les tests propres suivent cinq autres règles qui
  forment l’acronyme F.I.R.S.T

Answer 20

• 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.

Question 21

Stratégies de développement
des tests unitaires
! Right-BICEP Guidelines

Answer 21

• 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 ?

Question 22

Stratégies de développement
des tests unitaires
! RIGHT

Answer 22

• 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.

Question 23

Stratégies de développement
des tests unitaires
! Boundary check - CORRECT

Answer 23

• 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?

Question 24

Stratégies de développement
des tests unitaires

Answer 24

! 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