3. 3
Introduction:
La réalisation de programmes peut être une tâche complexe,
et il n'est pas toujours évident de parvenir rapidement au but
que l'on s'est fixé.
Il existe heureusement des méthodes et des outils qui
permettent de ne pas s'éloigner du but.
Tout au long du processus de développement, il faut veiller à
une chose : parvenir à finaliser le programme, en répondant au
cahier des charges fixé par le client.
Les tests font partie de ces outils qui aident le programmeur
dans ce sens.
4. 4 Orange diagrams library
Tests unitaires
Tests de
performance
Tests
fonctionnels et
d'intégration
Tests Fixture
Un test unitaire est un morceau de code écrit par
un développeur qui exécute une fonction
spécifique dans le code à tester.
C’est est un morceau de code qui permet de
fixer un environnement logiciel pour exécuter
des tests logiciels.
Un test d'intégration a comme but de tester le
comportement d'un composant ou de
l'intégration entre un ensemble de composants.
Les tests de performance sont utilisés pour
référencer les composants logiciels d'une
manière répétitive.
Les types de tests :
5. 5
Dans un projet
distinct
Un sujet
controversé
Tout code
trivial
Les parties critiquesUn code
existant
Des tests
logiciels
Organisation
des tests
Organisation des tests
6. 6
JUnit
JUnit est un framework de test unitaire. Il est intégré par
défaut dans les environnements de développement intégré
Java tels que BlueJ, Eclipse et NetBeans.
Junit utilise des annotations pour identifier les méthodes qui
spécifient un essai. En général, ces méthodes d'essai sont
contenues dans les TestCase.
JUnit définit deux
types de fichiers de
tests
Les TestC
ase
Une Test
Suite
7. 7
Pour écrire un test avec JUnit :
• Annoter une méthode avec the@org.junit.Test annotation
.
• Utiliser une méthode prévue par Junit.
Pour vérifier le résultat attendu de
l'exécution d’un code par rapport au
résultat réel.
L'interface utilisateur
d'Eclipse
org.junit.runner.JU
nitCore
8. 8
Annotation Description
@Test
public void method()
L'annotation @ Test identifie une méthode comme une
méthode d'essai.
@Test (expected =
Exception.class)
Échoue si la méthode ne lance pas l'exception
nommée.
@Test(timeout=100) Échoue si la méthode prend plus que 100
millisecondes.
@Before
public void method()
Cette méthode est exécutée avant chaque test.
@After
public void method()
Cette méthode est exécutée après chaque test. Elle
est utilisée pour le nettoyage de l'environnement de
test.
@BeforeClass
public static void method()
Elle est exécutée une seule fois, avant le début de tous
les tests. Les méthodes marquées par cette annotation
doivent être définies comme « static » pour pouvoir
travailler avec JUnit.
@AfterClass
public static void method()
Elle est exécutée une fois, après tous les tests ont été
achevés. Elle est utilisée po ur effectuer des activités
de « clean-up ».
@Ignore Ignorer la méthode d'essai. Elle est utile lorsque le
code sous-jacent a été changé et le TestCase n'a pas
encore été adapté. Ou si le temps d'exécution de ce
test est trop long pour être inclus.
9. 9
Statement Description
fail(String) Laissez la méthode échoue. Pour vérifier qu'une
certaine partie du code n'est pas atteinte ou pour
avoir un test échoué avant que le code de test est
mis en œuvre. Le paramètre «String » est facultatif.
assertTrue ([message], boolean
condition)
Vérifie que la condition booléenne est vraie.
assertFalse ([message], boolean
condition)
Vérifie que la condition booléenne est fausse.
assertEquals ([String message],
expected, actual)
Teste si deux valeurs sont les mêmes. Rq: pour les
tableaux la référence est vérifiée pas le contenu .
assertEquals ([String message],
expected, actual, tolerance)
Teste si des double ou float valeurs se
correspondent. La tolérance est le nombre de
décimales qui doit être le même.
assertNull ([message], object) Vérifie que l'objet est nul.
assertNotNull ([message], object) Vérifie que l'objet n’est pas nul.
assertSame ([String], expected,
actual)
Vérifie que les deux variables font référence au
même objet.
assertNotSame ([String],
expected, actual)
Vérifie que les deux variables font référence à des
objets différents.
Les Méthodes de test:
10. 10
Exemple: SimpleCalc Application
SimpleCalc Screen Layout:
• TextView control :header “Unit Testing
Sample.”
• Deux EditText controls: les entrées.
• Un FrameLayout control qui contient un
LinearLayout avec le result label TextView et le
TextView résultat.
• Un autre LinearLayout with : deux Boutons de
contrôle .
On a une seule activité: MainActivity.java
• Implémenter onClick() handlers pour les
deux boutons de contrôle: l’addition et la
multiplication.
• Il ya des bugs dans le code! Ces bugs ont
été conçus spécifiquement pour illustrer les
tests unitaires.
11. 11
Étape 1: Création d'un projet de test Android
•Ajouter un projet de test à tout projet Android de deux
façons:
En créant un nouveau projet Android avec l'Assistant de
projet Android.
Ajouter un projet de test à un projet Android existant.
Dans l'Explorateur de projet, choisir le projet Android que
vous souhaitez ajouter un projet de test:
12. 12
Étape2:Configuration du projet test Android
Le nom de projet
du test finit
généralement par
"Test"
Location
Le build target sera
sélectionné
automatiquement
lorsque vous
sélectionnez le
projet pour tester
Choisissez le
projet Android
à tester
Le nom
de projet
du test
13. 13
Étape3:Déterminer des tests unitaires pour l'application
SimpleCalc
Les tests unitaires peuvent augmenter considérablement la
stabilité et la qualité de votre application et de réduire les
coûts des essais.
Les tests unitaires peuvent:
Améliorer la couverture de test ;
Tester les hypothèses d'application ;
Valider les fonctionnalités de l'application ;
Dans notre cas,les tests unitaires peuvent être utilisés pour
tester les fonctionnalités de base:
• Le calcul SimpleCalc est effectué correctement?
• Vérifier si l'interface utilisateur affiche correctement.
14. 14
Étape4:Création de votre premier TestCase:
Pour créer votre premier test, click-droit sur le package
simplecalc.test et choisissez New> Junit TestCase.
15. 15
Étape 5 :Configuration de votre premier cas de test
JUnit 3,
Junit 4
sont
supportés
Test Case
MathValidation
Test Case
pour tester
une activité
Ajouter les
méthodes stubs
pour setUp() et
le constructeur
16. 16
•setUp () :est utilisée pour
définir une initialisation
générale utilisé par l'ensemble
des tests spécifiques.
• tearDown () :est ensuite
utilisée pour réinitialiser toutes
les ressources acquises par la
configuration de la méthode ().
construction
setUp()
tests run
tearDown()
destruction
Étape 6 :Examiner le TestCase MathValidation
Le cycle de vie d'un cas de test est essentiellement ceci
=> Implémenter le MathValidation
Test Case
17. 17
Étape 7:Modification de MathValidation Class Constructor
•Modifier le constructeur de la classe MathValidation.
Étape 8: Mettre en œuvre le MathValidation
méthode setUp ()• Recueillir les données nécessaires à la validation des
calculs mathématiques SimpleCalc
•Mettre en œuvre la méthode setUp ().
•Récupérer l'activité testée en utilisant getActivity
(méthode) comme suit:
19. 19
Étape 9: Étudier Tests pour l'application SimpleCalc
Quels sont les tests que vous souhaitez exécuter?
• Ajouter le code de test pour la classe MathValidation.
Étape 10 : Mettre en œuvre une méthode pour tester Ajout de
SimpleCalc
• Tester le calcul d'addition de SimpleCalc
• Ajouter une méthode appelée testAddValues ( ) à la classe
MathValidation
20. 20
Étape 11: Améliorer les tests pour Addition
S'assurer que tous les différents types de numéros
peuvent être ajoutés
Concaténer en un seul appel de méthode SendKeys ():
sendKeys(NUMBER_24 + NUMBER_74 +
"ENTER");
testAddDecimalValues() method.
21. 21
Étape 12: Exécution des tests unitaires avec l'émulateur
Android ou un périphérique
Pour exécuter les tests unitaires que vous avez créés
à partir de Eclipse
22. 22
Étape 13: Examen des résultats des tests
Un échec, c'est quand un test d’assertion échoue.
Une erreur, d'autre part, est une exception levée.
23. 23
Conclusion:
Quelques règles de bonne conduite avec JUnit:
Ecrire les test en même temps que le code.
Tester uniquement ce qui peut vraiment provoquer des
erreurs.
Exécuter des tests aussi souvent que possible,
idéalement après chaque changement de code.
Ecrire un test pour tout bogue signalé (même s’il est
corrigé).
Ne pas tester plusieurs méthodes dans un même test
:JUnit s’arrète à la première erreur.
Attention, les méthodes privées ne peuvent pas être
testées !