SlideShare une entreprise Scribd logo
Les Tests
Unitaires
Cour développé par
Akrouh Mohamed
Élève ingénieur à l’Ecole National
des Sciences Appliquées
Al-Hoceima.
Asrihi Yousra
Élève ingénieur à l’Ecole National
des Sciences Appliquées
Al-Hoceima.
Dans le cadre des projets de fin de semestre, nous sommes en tâche de préparer un cours sur les
tests unitaires. Ce travail est demandé par Madame LAMIAE notre enseignante du module Qualité
Logiciel.
2
Sabbani Anas
Élève ingénieur à l’Ecole National
des Sciences Appliquées
Al-Hoceima.
Merci!
On vous remercie d'être présent avec nous.
3
Software
Testing
Introduction
1
“Les tests logiciels est une activité
permettant de vérifier si les résultats
réels correspondent aux résultats
attendus et de s’assurer que le
système logiciel est sans défaut.
5
Vidéo
Cette vidéo montre un aspect de l’importances de
travailler avec des tests.
6
7
Les types
des tests
2
Les catégories de
tests logiciel
○ Les tests fonctionnels
○ Les tests non fonctionnels
○ Maintenance
Il faut noter que ces types ne sont pas applicables
à tous les projets. Cela dépend souvent de la
nature et de la portée de ce dernier.
9
Tests Fonctionnels
10
On parle de tests fonctionnels quand il s'agit de vérifier qu'une classe permet
bien de remplir avec succès l'objectif fixé par un cas d'utilisation donné. Un
test fonctionnel permet de répondre à la question « est-ce que le code permet
de faire ça ? » ou « est-ce que cette fonctionnalité attendue est bien
fonctionnelle ?
Tests Non-Fonctionnels
11
les tests non-fonctionnels vérifient des propriétés qui ne sont pas directement
liées à une utilisation du code. Il s'agit de vérifier des caractéristiques telle que
la sécurité ou la capacité à monter en charge. Les tests non-fonctionnels
permettent plutôt de répondre à des questions telles que « est-ce que cette
classe peut être utilisée par 1000 threads en même temps sans erreur ? ».
Maintenance
12
Selon la définition de l'AFNOR, la maintenance vise à maintenir ou à rétablir un bien dans un état
spécifié afin que celui-ci soit en mesure d'assurer un service déterminé .
La maintenance regroupe ainsi les actions de dépannage et de réparation, de réglage, de révision,
de contrôle et de vérification des logiciels.
Un service de maintenance peut également être amené à participer à des études d'amélioration du
processus industriel, et doit, comme d'autres services de l'entreprise, prendre en considération de
nombreuses contraintes comme la qualité, la sécurité, l'environnement, le coût, etc.
Les types de test
logiciel
13
Categories Type
Test
fonctionnels
Unit Testing - Integration Testing
Test non
fonctionnels
Performance - Endurance
Load - Volume
Maintenance
Regression - Maintenance
TESTS AUTOMATISÉS
14
Déf: Un test automatisé est un test dont l'exécution ne
nécessite pas l'intervention d'un humain.
L'exécution de tests automatisés requiert donc l'utilisation
de solutions informatiques dont le but est d'exécuter des
actions, soit spécifiquement dans un navigateur web, soit
plus généralement au niveau du système d'exploitation.
TESTS AUTOMATISÉS
15
Beaucoup de tests relativement basiques doivent être réalisés très régulièrement durant le cycle de
vie d'un logiciel, ce qui rend leur exécution manuelle fastidieuse pour un ROI faible. D'autre part,
dans certains contextes (projets web notamment), les tests doivent être réalisés sur différentes
plateformes, différents navigateurs de différentes versions, etc.
Avantage : ces scripts peuvent être réutilisés pour tester votre produit ultérieurement.
Inconvénient : cela implique un temps et un coût de création.
Tests Manuels
16
Lors de tests manuels, c’est une personne, un testeur expérimenté, qui va naviguer dans votre produit. Il l’utilise
comme le feront vos futurs utilisateurs. Les tests manuels peuvent se dérouler de deux façons différentes :
Test avec scénario - Le testeur suit des parcours définis au préalable pour contrôler la qualité de l’application sur
des problématiques bien précises.
Test exploratoire - Le testeur navigue librement dans l’application pour y déceler le maximum de bugs et de
problèmes.
Tests Manuels
17
Avantage : Contrairement au test automatisé, le test manuel vous permet de tester l’UI (user
interface) et UX (user experience) de votre produit : l’affichage correct du texte, les liens, les
images. Cela vous permet de déceler des bugs qui seraient visibles par vos utilisateurs mais
n’auraient pas pu être repérés par un robot.
Inconvénient : Les tests manuels ne peuvent pas être répliqués aussi facilement que les tests
automatisés.
TEST
UNITAIRE
3
“Un test unitaire est un procédé
permettant de s'assurer du bon
fonctionnement d'une unité de
programme.
19
Il s’agit simplement de vérifier, en fonction
de certaines données fournies en entrée
d’un module de code , que les données qui
en sortent ou les actions qui en découlent
sont conformes aux spécifications du
module.
Définition
20
Le test définit un critère d'arrêt (état ou
sorties à l'issue de l'exécution) et permet de
statuer sur le succès ou sur l'échec d'une
vérification. Grâce à la spécification, on est
en mesure de faire correspondre un état
d'entrée donné à un résultat ou à une sortie.
Le test permet de vérifier que la relation
d'entrée / sortie donnée par la spécification
est bel et bien réalisée.
utilité
21
utilité
22
● Trouver les erreurs rapidement
● Sécuriser la maintenance
● Documenter le code:
Il est possible que la documentation ne soit plus à jour, mais les
tests eux correspondent à la réalité de l'application.
Quand tester ??
23
Fonctionnement
24
On définit généralement 4 phases dans l'exécution d'un test unitaire :
1. Initialisation (fonction setUp) : définition d'un environnement de test complètement
reproductible (une fixture).
2. Exercice : le module à tester est exécuté.
3. Vérification (utilisation de fonctions assert) : comparaison des résultats obtenus
avec un vecteur de résultat défini. Ces tests définissent le résultat du test : SUCCÈS
(SUCCÈS) ou ÉCHEC (FAILURE).
4. Désactivation (fonction tearDown) : désinstallation des fixtures pour retrouver l'état
initial du système, dans le but de ne pas polluer les tests suivants. Tous les tests
doivent être indépendants et reproductibles unitairement (quand exécutés seuls).
Cycle de vie d’un test
25
Software Testing Life Cycle (STLC):
Utilisation des mocks
26
Les mocks sont des objets permettant de simuler un objet réel de façon contrôlée.
Dans certains cas, l'utilisation de mock est primordiale, pour un gain de temps de couverture
de code, et de fiabilité des tests.
● pour simuler une base de données, un service web, etc., les interactions entre
l'application et ces outils prennent du temps, l'utilisation de mock pour simuler leurs
fonctionnements peut être un gain de temps considérable ;
● certains cas d'erreurs sont très difficile à reproduire, l'utilisation de mock permet ici
de simuler une erreur pour pouvoir traiter ce cas et donc améliorer la couverture de
code, par exemple le catch d'une exception ;
● sans l'utilisation de mock, le test peut retourner une erreur ne provenant pas du code
qui est testé (par exemple une base de données).
Outils de Test
Unitaire
27
❖ AUnit11 pour Ada ;
❖ ASUnit12 pour ActionScript ;
❖ Cppunit13 pour C++ ;
❖ CUnit14 pour C ;
❖ DUnit pour Delphi ;
❖ FLEXunit pour Adobe Flex ;
❖ Google Test15 et Boost Test16 pour C++ ;
❖ HUnit17 pour Haskell ;
❖ JSUnit18, QUnit19 et Unit.js20 pour JavaScript
❖ Tape pour JavaScript ;
❖ Test::Unit pour Ruby ;
❖ Test::More pour Perl ;
❖ JUnit21 et TestNG22 pour Java ;
❖ NUnit23 pour .NET ;
❖ Microsoft Unit Test24 pour .NET ;
❖ xUnit25 pour .NET ;
❖ NUnitASP26 pour ASP.NET
❖ OUnit27 pour OCaml ;
❖ OCunit pour Objective C ;
❖ PBUnit pour PowerBuilder;
❖ PHPUnit28, SimpleTest29 et Atoum30 pour PHP ;
❖ utPLSQL 31 pour PL/SQL ;
❖ Unittest et PyUnit pour Python ;
JUnit
28
est un framework de test unitaire pour le langage de programmation Java.
Créé par Kent Beck et Erich Gamma, JUnit est certainement le projet de la série
des xUnitconnaissant le plus de succès.
JUnit définit deux types de fichiers de tests. Les TestCase (cas de test) sont
des classes contenant un certain nombre de méthodes de tests. Un TestCase
sert généralement à tester le bon fonctionnement d'une classe. Une TestSuite
permet d'exécuter un certain nombre de TestCase déjà définis.
Dans un TestCase il n'y a pas de main méthod, chaque test étant indépendant.
JUnit est intégré par défaut dans les environnements de développement intégré
Java tels que BlueJ, Eclipse et NetBeans.
29
Cppunit
30
CppUnit est un module d'infrastructure de
test unitaire pour le langage de
programmation C ++. Il permet des tests
unitaires des sources C ainsi que du C ++
avec une modification minimale de la
source
PHPUnit28
31
Créé par Sebastian Bergmann en
2004, il intègre les concepts communs
aux bibliothèques de tests unitaires
xUnit. le code source de PHPUnit est
hébergé sur GitHub
32
Exemple de teste unitaire avec PHPUnit
Vidéo
33
34
Avantage,
limites et best
practices
Fin
4
○ Ils permettent notamment de documenter
automatiquement le code source. En effet, la
lecture des tests permet de comprendre le
comportement attendu du code, et donc le
fonctionnement de l’application, tant
technique que logique.
Avantage
36
○ Les développeurs peuvent appréhender
toutes les fonctionnalités apporté par un
système.
○ Nous pouvons tester des parties du projet
sans attendre que d'autres soient terminées.
Avantage
37
○ Les tests automatisés représentent
donc un formidable outil de
non-régression
Avantage
38
○ Les tests unitaires ne détectent pas toutes les
erreurs.
○
Limite
39
○ Les tests unitaires ne peuvent pas l'évaluer tous
les chemins d'exécution,
○
Limite
40
○
○ Les tests unitaires sont centrés sur une unité de
code, il ne peuvent pas détecter les erreurs
d'intégration.
Limite
41
Best Practices
Les cas de tests unitaires doivent être
indépendants.
En cas d'amélioration ou de modification
des exigences, les tests élémentaires ne
doivent pas être affectés.
42
Best Practices
Ne testez qu'un code à la fois.
43
Best Practices
Suivez les conventions de dénomination
claires et cohérentes pour vos tests
unitaires
44
Best Practices
En cas de changement de code dans un
module, assurez-vous qu'il existe un
scénario de test d'unité correspondant pour
le module et que le module réussisse les
tests avant de modifier la mise en œuvre.
45
Best Practices
Plus vous écrivez de code sans avoir à
tester, plus vous aurez de chemins à vérifier
pour détecter les erreurs.
46
L'approche TDD(Test-Driven-Development)
Il existe trois approches concernant les tests unitaires :
1. Les développeurs n'en écrivent jamais (ne riez pas, c'est
malheureusement la majorité des cas) ;
2. Les développeurs écrivent les tests quand ils ont le temps et la
motivation (c'est à dire très rarement) ;
3. Les développeurs commencent par écrire les tests avant toute
ligne de code métier.
47
TDD
1. Cette dernière
approche porte un
nom : le TDD, pour
Test-Driven-Developme
nt. La règle est assez
simple : vous
commencez par écrire
les tests qui permettent
de valider les
différentes exigences
de votre application.
Ensuite, vous écrivez le
code de votre
application qui permet
de valider ces tests.
2. Cette méthode permet
d'éviter d'écrire trop de code. La
base de code est plus saine et
moins sujette aux erreurs. D'un
autre côté, il n'est pas toujours
évident d'avoir cette approche
avec des tests d'interface ou
lorsqu'une connectivité réseau
est présente. Car les paramètres
qui rentrent en compte sont
multiples.
3. Pour faire simple, cette
approche est intéressante pour
tester son modèle, et c'est ce que
nous allons voir dans les prochains
chapitres.
48
Application
5
Conclusion
6
Merci de votre
attention 51

Contenu connexe

Test unitaires

  • 2. Cour développé par Akrouh Mohamed Élève ingénieur à l’Ecole National des Sciences Appliquées Al-Hoceima. Asrihi Yousra Élève ingénieur à l’Ecole National des Sciences Appliquées Al-Hoceima. Dans le cadre des projets de fin de semestre, nous sommes en tâche de préparer un cours sur les tests unitaires. Ce travail est demandé par Madame LAMIAE notre enseignante du module Qualité Logiciel. 2 Sabbani Anas Élève ingénieur à l’Ecole National des Sciences Appliquées Al-Hoceima.
  • 3. Merci! On vous remercie d'être présent avec nous. 3
  • 5. “Les tests logiciels est une activité permettant de vérifier si les résultats réels correspondent aux résultats attendus et de s’assurer que le système logiciel est sans défaut. 5
  • 6. Vidéo Cette vidéo montre un aspect de l’importances de travailler avec des tests. 6
  • 7. 7
  • 9. Les catégories de tests logiciel ○ Les tests fonctionnels ○ Les tests non fonctionnels ○ Maintenance Il faut noter que ces types ne sont pas applicables à tous les projets. Cela dépend souvent de la nature et de la portée de ce dernier. 9
  • 10. Tests Fonctionnels 10 On parle de tests fonctionnels quand il s'agit de vérifier qu'une classe permet bien de remplir avec succès l'objectif fixé par un cas d'utilisation donné. Un test fonctionnel permet de répondre à la question « est-ce que le code permet de faire ça ? » ou « est-ce que cette fonctionnalité attendue est bien fonctionnelle ?
  • 11. Tests Non-Fonctionnels 11 les tests non-fonctionnels vérifient des propriétés qui ne sont pas directement liées à une utilisation du code. Il s'agit de vérifier des caractéristiques telle que la sécurité ou la capacité à monter en charge. Les tests non-fonctionnels permettent plutôt de répondre à des questions telles que « est-ce que cette classe peut être utilisée par 1000 threads en même temps sans erreur ? ».
  • 12. Maintenance 12 Selon la définition de l'AFNOR, la maintenance vise à maintenir ou à rétablir un bien dans un état spécifié afin que celui-ci soit en mesure d'assurer un service déterminé . La maintenance regroupe ainsi les actions de dépannage et de réparation, de réglage, de révision, de contrôle et de vérification des logiciels. Un service de maintenance peut également être amené à participer à des études d'amélioration du processus industriel, et doit, comme d'autres services de l'entreprise, prendre en considération de nombreuses contraintes comme la qualité, la sécurité, l'environnement, le coût, etc.
  • 13. Les types de test logiciel 13 Categories Type Test fonctionnels Unit Testing - Integration Testing Test non fonctionnels Performance - Endurance Load - Volume Maintenance Regression - Maintenance
  • 14. TESTS AUTOMATISÉS 14 Déf: Un test automatisé est un test dont l'exécution ne nécessite pas l'intervention d'un humain. L'exécution de tests automatisés requiert donc l'utilisation de solutions informatiques dont le but est d'exécuter des actions, soit spécifiquement dans un navigateur web, soit plus généralement au niveau du système d'exploitation.
  • 15. TESTS AUTOMATISÉS 15 Beaucoup de tests relativement basiques doivent être réalisés très régulièrement durant le cycle de vie d'un logiciel, ce qui rend leur exécution manuelle fastidieuse pour un ROI faible. D'autre part, dans certains contextes (projets web notamment), les tests doivent être réalisés sur différentes plateformes, différents navigateurs de différentes versions, etc. Avantage : ces scripts peuvent être réutilisés pour tester votre produit ultérieurement. Inconvénient : cela implique un temps et un coût de création.
  • 16. Tests Manuels 16 Lors de tests manuels, c’est une personne, un testeur expérimenté, qui va naviguer dans votre produit. Il l’utilise comme le feront vos futurs utilisateurs. Les tests manuels peuvent se dérouler de deux façons différentes : Test avec scénario - Le testeur suit des parcours définis au préalable pour contrôler la qualité de l’application sur des problématiques bien précises. Test exploratoire - Le testeur navigue librement dans l’application pour y déceler le maximum de bugs et de problèmes.
  • 17. Tests Manuels 17 Avantage : Contrairement au test automatisé, le test manuel vous permet de tester l’UI (user interface) et UX (user experience) de votre produit : l’affichage correct du texte, les liens, les images. Cela vous permet de déceler des bugs qui seraient visibles par vos utilisateurs mais n’auraient pas pu être repérés par un robot. Inconvénient : Les tests manuels ne peuvent pas être répliqués aussi facilement que les tests automatisés.
  • 19. “Un test unitaire est un procédé permettant de s'assurer du bon fonctionnement d'une unité de programme. 19
  • 20. Il s’agit simplement de vérifier, en fonction de certaines données fournies en entrée d’un module de code , que les données qui en sortent ou les actions qui en découlent sont conformes aux spécifications du module. Définition 20
  • 21. Le test définit un critère d'arrêt (état ou sorties à l'issue de l'exécution) et permet de statuer sur le succès ou sur l'échec d'une vérification. Grâce à la spécification, on est en mesure de faire correspondre un état d'entrée donné à un résultat ou à une sortie. Le test permet de vérifier que la relation d'entrée / sortie donnée par la spécification est bel et bien réalisée. utilité 21
  • 22. utilité 22 ● Trouver les erreurs rapidement ● Sécuriser la maintenance ● Documenter le code: Il est possible que la documentation ne soit plus à jour, mais les tests eux correspondent à la réalité de l'application.
  • 24. Fonctionnement 24 On définit généralement 4 phases dans l'exécution d'un test unitaire : 1. Initialisation (fonction setUp) : définition d'un environnement de test complètement reproductible (une fixture). 2. Exercice : le module à tester est exécuté. 3. Vérification (utilisation de fonctions assert) : comparaison des résultats obtenus avec un vecteur de résultat défini. Ces tests définissent le résultat du test : SUCCÈS (SUCCÈS) ou ÉCHEC (FAILURE). 4. Désactivation (fonction tearDown) : désinstallation des fixtures pour retrouver l'état initial du système, dans le but de ne pas polluer les tests suivants. Tous les tests doivent être indépendants et reproductibles unitairement (quand exécutés seuls).
  • 25. Cycle de vie d’un test 25 Software Testing Life Cycle (STLC):
  • 26. Utilisation des mocks 26 Les mocks sont des objets permettant de simuler un objet réel de façon contrôlée. Dans certains cas, l'utilisation de mock est primordiale, pour un gain de temps de couverture de code, et de fiabilité des tests. ● pour simuler une base de données, un service web, etc., les interactions entre l'application et ces outils prennent du temps, l'utilisation de mock pour simuler leurs fonctionnements peut être un gain de temps considérable ; ● certains cas d'erreurs sont très difficile à reproduire, l'utilisation de mock permet ici de simuler une erreur pour pouvoir traiter ce cas et donc améliorer la couverture de code, par exemple le catch d'une exception ; ● sans l'utilisation de mock, le test peut retourner une erreur ne provenant pas du code qui est testé (par exemple une base de données).
  • 27. Outils de Test Unitaire 27 ❖ AUnit11 pour Ada ; ❖ ASUnit12 pour ActionScript ; ❖ Cppunit13 pour C++ ; ❖ CUnit14 pour C ; ❖ DUnit pour Delphi ; ❖ FLEXunit pour Adobe Flex ; ❖ Google Test15 et Boost Test16 pour C++ ; ❖ HUnit17 pour Haskell ; ❖ JSUnit18, QUnit19 et Unit.js20 pour JavaScript ❖ Tape pour JavaScript ; ❖ Test::Unit pour Ruby ; ❖ Test::More pour Perl ; ❖ JUnit21 et TestNG22 pour Java ; ❖ NUnit23 pour .NET ; ❖ Microsoft Unit Test24 pour .NET ; ❖ xUnit25 pour .NET ; ❖ NUnitASP26 pour ASP.NET ❖ OUnit27 pour OCaml ; ❖ OCunit pour Objective C ; ❖ PBUnit pour PowerBuilder; ❖ PHPUnit28, SimpleTest29 et Atoum30 pour PHP ; ❖ utPLSQL 31 pour PL/SQL ; ❖ Unittest et PyUnit pour Python ;
  • 28. JUnit 28 est un framework de test unitaire pour le langage de programmation Java. Créé par Kent Beck et Erich Gamma, JUnit est certainement le projet de la série des xUnitconnaissant le plus de succès. JUnit définit deux types de fichiers de tests. Les TestCase (cas de test) sont des classes contenant un certain nombre de méthodes de tests. Un TestCase sert généralement à tester le bon fonctionnement d'une classe. Une TestSuite permet d'exécuter un certain nombre de TestCase déjà définis. Dans un TestCase il n'y a pas de main méthod, chaque test étant indépendant. JUnit est intégré par défaut dans les environnements de développement intégré Java tels que BlueJ, Eclipse et NetBeans.
  • 29. 29
  • 30. Cppunit 30 CppUnit est un module d'infrastructure de test unitaire pour le langage de programmation C ++. Il permet des tests unitaires des sources C ainsi que du C ++ avec une modification minimale de la source
  • 31. PHPUnit28 31 Créé par Sebastian Bergmann en 2004, il intègre les concepts communs aux bibliothèques de tests unitaires xUnit. le code source de PHPUnit est hébergé sur GitHub
  • 32. 32 Exemple de teste unitaire avec PHPUnit
  • 34. 34
  • 36. ○ Ils permettent notamment de documenter automatiquement le code source. En effet, la lecture des tests permet de comprendre le comportement attendu du code, et donc le fonctionnement de l’application, tant technique que logique. Avantage 36
  • 37. ○ Les développeurs peuvent appréhender toutes les fonctionnalités apporté par un système. ○ Nous pouvons tester des parties du projet sans attendre que d'autres soient terminées. Avantage 37
  • 38. ○ Les tests automatisés représentent donc un formidable outil de non-régression Avantage 38
  • 39. ○ Les tests unitaires ne détectent pas toutes les erreurs. ○ Limite 39
  • 40. ○ Les tests unitaires ne peuvent pas l'évaluer tous les chemins d'exécution, ○ Limite 40
  • 41. ○ ○ Les tests unitaires sont centrés sur une unité de code, il ne peuvent pas détecter les erreurs d'intégration. Limite 41
  • 42. Best Practices Les cas de tests unitaires doivent être indépendants. En cas d'amélioration ou de modification des exigences, les tests élémentaires ne doivent pas être affectés. 42
  • 43. Best Practices Ne testez qu'un code à la fois. 43
  • 44. Best Practices Suivez les conventions de dénomination claires et cohérentes pour vos tests unitaires 44
  • 45. Best Practices En cas de changement de code dans un module, assurez-vous qu'il existe un scénario de test d'unité correspondant pour le module et que le module réussisse les tests avant de modifier la mise en œuvre. 45
  • 46. Best Practices Plus vous écrivez de code sans avoir à tester, plus vous aurez de chemins à vérifier pour détecter les erreurs. 46
  • 47. L'approche TDD(Test-Driven-Development) Il existe trois approches concernant les tests unitaires : 1. Les développeurs n'en écrivent jamais (ne riez pas, c'est malheureusement la majorité des cas) ; 2. Les développeurs écrivent les tests quand ils ont le temps et la motivation (c'est à dire très rarement) ; 3. Les développeurs commencent par écrire les tests avant toute ligne de code métier. 47
  • 48. TDD 1. Cette dernière approche porte un nom : le TDD, pour Test-Driven-Developme nt. La règle est assez simple : vous commencez par écrire les tests qui permettent de valider les différentes exigences de votre application. Ensuite, vous écrivez le code de votre application qui permet de valider ces tests. 2. Cette méthode permet d'éviter d'écrire trop de code. La base de code est plus saine et moins sujette aux erreurs. D'un autre côté, il n'est pas toujours évident d'avoir cette approche avec des tests d'interface ou lorsqu'une connectivité réseau est présente. Car les paramètres qui rentrent en compte sont multiples. 3. Pour faire simple, cette approche est intéressante pour tester son modèle, et c'est ce que nous allons voir dans les prochains chapitres. 48