2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.1
J. Paul Gibson
http://www-public.it-sudparis.eu/~gibson/
Bureau A 207, Le département LOgiciels-Réseaux
Thanks to: Christian Bac, Denis Conan & Jean-Luc Raffy
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.2
I.Rappels sur les testsII. Comment utiliser les modèles OO en UML?III. Étude de cas – médiathèque
A) Préparation1. Tests de validation2. Tests d’intégration3. Tests unitaires
B) Codage et Exécution4. Tests unitaires avec JUnit5. Tests d’intégration6. Tests de validation
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.3
I.Rappels sur les tests
Le cycle en V
Spécification
Conception préliminaire
Conception détaillée
Codage (système et tests)
Tests unitaires
Tests d’intégration
Validationpréparation
préparation
préparation
Codage et exécution
Codage etexécution
Codage et exécution
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.4
Tests are the main way of maintaining consistency in the documentation/models:
• Natural Language Text (English/French)• (UML) models• (Java) Code• Comments in (Java) Code
If you do not develop tests in parallel with code you risk having widespread inconsistency that is difficult to fix (particularly in large projects with lots of team members working on different phases of the development).
Testing Consistency (not uniquely OO)
NOTE: testing after all the code is developed is usually a bad idea, but it is better than no testing at all!
I.Rappels sur les tests
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.5
Niveaux de test - pour chaque (sous)système• Tests de validation
• Tests d’intégration
• Tests unitaires
Préparation
exécution
SystèmeSous-système
I.Rappels sur les tests
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.6
UML – les diagrammes1. Niveau Application (spécification)
– Diagramme des cas d’utilisation – Niveau Sous-Système (Analyse et conception)
• test des associations, des agrégations (diagramme de classes)– multiplicité– création, destruction
• test de séquences (diagramme de séquence et de communications)– construction d’un graphe de flot
• test des exceptions contrȏlées – Diagramme des classes (ébauche)– Diagrammes de séquence/communications
2. Niveau Classes (conception détaillée)– Classes détaillées– Diagrammes de machine à états
II. (OO) modeles en UML
Tests de validation
Tests d’intégration
Tests unitaires
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.7
A key principle with testing is that the tests should be derived from (and be consistent with) the requirements specification.
The UML diagrams should help us because:
• if our tests are consistent with the UML then – provided the UML is validated against the informally expressed needs of the client – we have a good chance of properly testing the system against what is really required by the client/customer
• the structure of the UML should correspond to the structure of the developed code – it is a bridge between what is required and how it is to be implemented – so we can re-use this design structure to structure our tests.
How to Use UMLII. (OO) modeles en UML
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.8
Validation
II. (OO) modeles en UML
Use Case Diagrams – for each use case examine possible scenarios, and choose a subset of alternative paths for testing. For example:
Use case1
Use case2
Use case3
Use case4
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.9
Integration : composition tree II. (OO) modeles en UML
The test sequence can be decided by looking at the tree-like structure of composition hierarchies. For example:
Note: in reality, one rarely sees a tree due to shared components and cyclic dependencies. However, one can always find a reasonable tree abstraction from any given composition hierachy.
SystèmeComposition tree
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.10
Integration : big bang approach
Big Bang – system validation – « if the system works then it must be properly integrated? »
II. (OO) modeles en UML
Test at the system interface
MAIN PROBLEMS: • Testing produces errors, but what caused them?• Testing misses bugs • Testing starts after all components are coded
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.11
Integration : top down approachTop Down– test all interactions between components (from root to leaves).
II. (OO) modeles en UML
Possible integration test sequence (depth first)
7 8
4 5 6
2 31
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.12
Integration : stubs
Top Down– the need for stubs (to replace as yet unimplemented lower-level components)
II. (OO) modeles en UML
In top down testing, we may start the tests before all components are coded. In such a case, we may have to write stubs – pieces of dummy code that simulate behaviour that is not yet coded. In OO, stubs simulate called methods.
Mediatheque
FicheEmprunt
Client
To test the integration between the mediatheque and the ficheEmprunt, we may have to write a stub which simulates part of the client’s behaviour
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.13
Integration : bottom up approach
Bottom-Up– test all interactions between components (from leaves to root).
II. (OO) modeles en UML
Possible integration test sequence (depth first)
1 2
3 4 5
7 86
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.14
Integration : drivers
Bottom-Up– the need for drivers (to replace as yet unimplemented higher-level components)
II. (OO) modeles en UML
In bottom up testing, we may start the tests before all components are coded. In such a case, we may have to write drivers– pieces of dummy code that simulate behaviour that is not yet coded. In OO, drivers simulate calling methods
Mediatheque
FicheEmprunt
Client
To test the integration between the client and the ficheEmprunt, we may have to write a driver which simulates part of the behaviour of the mediatheque
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.15
Les tests unitaires
II. (OO) modeles en UML
• Il faut tester les invariants de chaque classe
• Il faut tester la fonctionnalité de chaque méthode de chaque classe
• Des classes avec des contraintes séquencielles sur l’activation des méthodes et leurs clients peuvent avoir des erreurs de séquencement.
=> Le comportement requis doit être testé en utilisant un modèle de machine à états
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.16
III. Etude de cas
A) Préparation1. Tests de validation, e.g.: Emprunter2. Tests d’intégration, e.g.: Emprunter3. Tests unitaires, e.g.: Document
B) Codage et Exécution4. Tests unitaires avec JUnit5. Tests d’intégration6. Tests de validation
Comment Tester la Médiathèque?
Présentation Séquence135
642
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.17
Préparation
1. Tests de validation, eg: Emprunter
2. Tests d’intégration, eg: Emprunter
3. Tests unitaire, eg: Document
B) Codage et Exécution4. Tests unitaire avec JUnit5. Tests d’intégration
6. Tests de validation
Comment Tester la Médiathèque? III. Etude de cas
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.18
Emprunter
A validation test (is a black box test - usually done by the client - that validates the (partial) behaviour of the whole system.
The UML use case diagrams help us to identify good candidates for validation tests.
We will test the emprunter functionality
III. Etude de cas – Préparation Tests de Validation
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.19
Emprunter
Données d’entrée
client: peut être inscrit ou non;
emprunts: déja effectués par le client
• existe-t-il un emprunt en retard ?
• le nombre de documents empruntés correspond-il au nombre maximum de ce client ?
document: • existe?
• empruntable ou consultable?,
• déjà emprunté ou disponible?
III. Etude de cas – Préparation Tests de Validation
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.20
Emprunter
Données de sortieEmprunt accepté ou refusé.
Remarque: la définition des jeux de tests de validation pour le cas d’utilisation emprunter document permet de soulever au moins les questions suivantes (à poser au client):
• un abonné qui n’est pas à jour de sa cotisation peut-il tout de même emprunter un document?• doit-il être considéré comme un client au tarif normal tant qu’il n’a pas renouvelé son abonnement?• ou doit-il se réabonner avant de pouvoir emprunter un document?
D’une manière générale, la préparation des jeux de tests de validation permet de lever les ambiguïtés et les vides de la spécification.
NOTE : Plus les tests sont préparés tôt et moins les corrections coûtent chères
III. Etude de cas – Préparation Tests de Validation
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.21
Emprunter
Table de décisions
III. Etude de cas – Préparation Tests de Validation
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.22
Emprunter
Test 1 - Client n'est pas inscrit
Test Code Steps:
1. Intialise dummy Mediatheque2. Check state of current Mediatheque (including statistics)3. Attempt to « emprunter » a document for a client who does not exist4. Check state of current Mediatheque (including statistics)
III. Etude de cas – Préparation Tests de Validation
To illustrate the testing process, we will treat the first 2 test cases
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.23
Emprunter
Test 2 - Client possède un emprunt qui est en retard
Test Code Steps:
1. Intialise dummy Mediatheque2. Check state of current Mediatheque (including statistics)3. Authorise « emprunter » of a document for a client4. Advance the date so that the previous « emprunt » is now
past its deadline5. Attempt to « emprunter » by the same client before they
return the document that is past its deadline6. Check state of current Mediatheque (including statistics)
III. Etude de cas – Préparation Tests de Validation
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.24
A) Préparation
1. Tests de validation, e.g.: Emprunter
2. Tests d’intégration, e.g.: Emprunter
3. Tests unitaires, e.g.: Document
B) Codage et Exécution
4. Tests unitaires avec JUnit
5. Tests d’intégration
6. Tests de validation
Comment Tester la Médiathèque ? III. Etude de cas
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.25
Validation TestsIII. Etude de cas –Tests de Validation - Codage et Execution
Even if our system is not yet completely developed, we can write the code for the validation tests; and compile and run the tests once the system is completely developed.
For this example, we will code the validation test as a JUnit test on the mediatheque class.
NOTE: A validation of the overall system is often known as an acceptance test; and can be thought of as a system unit test.
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.26
III. Etude de cas –Tests de Validation - Codage et Execution
@Beforepublic void setUp() throws Exception {// un test de validation est un test unitaire sur la classe Mediathequem1 = new Mediatheque("mediatheque test");Genre g = new Genre("Test_nom1");Localisation l = new Localisation("Test_salle1","Test_rayon1");Document d1 = new Video("Test_code1",l, "Test_titre1", "Test_auteur1", "");Document d2 = new Video("Test_code2",l, "Test_titre2", "Test_auteur2", "Test_annee2" ,g, "Test_duree2", "Test_mentionLegale2");
m1.ajouterDocument(d1); m1.metEmpruntable("Test_code1");m1.ajouterDocument(d2); m1.metEmpruntable("Test_code2");
CategorieClient cat = new CategorieClient("Test_Cat1", 10, 1.5, 2.5, 3.5, true);Client c1 = new Client("Test_Client_Nom1", "Test_Client_Prenom1", "Test_Client_Address1",cat); m1.inscrire(c1);Client c2 = new Client("Test_Client_Nom2", "Test_Client_Prenom2", "Test_Client_Address2",cat);}
@Afterpublic void tearDown() throws Exception {m1 = null;}
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.27
Test 1 - Client n'est pas inscrit
III. Etude de cas –Tests de Validation - Codage et Execution
/** * Document TEST 1<br> * Client n'est pas inscrit */@Test\\ @Test (expected= OperationImpossible.class) – if we expect an exceptionpublic void clientPasInscrit( ) throws OperationImpossible, InvariantBroken{
// assertions on state of m1 before emprunter
m1.emprunter("nom", "prenom", "Test_code1");
// assertions on state of m1 after emprunter
}
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.28
Test 2 - Client n'est pas sans retard
III. Etude de cas –Tests de Validation - Codage et Execution
/** * Document TEST 2<br> * Client n'est pas sans retard */@Test\\ @Test (expected= OperationImpossible.class) – if we expect an exceptionpublic void clientAvecRetard( ) throws OperationImpossible, InvariantBroken{
// assertions on state of m1 before emprunterm1.emprunter("nom1", "prenom1", "Test_code1");
Datutil.addAuJour(7);Datutil.addAuJour(7);
m1.emprunter("nom1", "prenom1", "Test_code2");// assertions on state of m1 after emprunter
}
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.29
A) Préparation
1. Tests de validation, e.g.: Emprunter
2. Tests d’intégration, eg: Emprunter
3. Tests unitaires, e.g.: Document
B) Codage et Exécution4. Tests unitaires avec JUnit5. Tests d’intégration6. Tests de validation
Comment Tester la Médiathèque ?III. Etude de cas
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.30
Emprunter
The operation « emprunter » requires co-ordination between the
• client,• mediatheque,• document, and• ficheEmprunt objects
We wish to verify that the traces (of communication) between the objects involved in the collaboration, as specified in UML, are executed by the implementation (in Java), following the specified temporal ordering.
These tests can be derived from the communications and/or sequence diagrams …
III. Etude de cas – Préparation Tests d’intégration
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.31
Emprunter
In the communications diagram, the temporal order is specified by the numbering
III. Etude de cas – Préparation Tests d’intégration
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.32
EmprunterThe co-ordination between theClient and the Document:
Integration Test 1An « emprunt » is not authorised because the document is not « empruntable »
Integration Test 2An « emprunt » is not authorised because the document is « emprunté »
Integration Test 3Emprunt is authorised
III. Etude de cas – Préparation Tests d’intégration
12
3456 6.1 6.2 6.2.1 6.3 6.3.1 6.4 6.4.16.5 6.6 6.6.1
Note: integration tests do not usually require all components to be implemented fully
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.33
Emprunter
Integration Test1 - An « emprunt » is not authorised because the document is not empruntable
• Construct a document,and make it not Empruntable
• Construct a client
• Construct a FicheEmprunt for the client and document
• Check that:1. the system handles the exceptional case in a meaningful way2. the client and document states/statistics have not been
changed
III. Etude de cas –Tests d’Integration - Codage et Execution
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.34
Emprunter
Integration Test 2 Design: An « emprunt » is not authorised because the document is « emprunté »
• Construct a document, which is empruntable and emprunté
• Construct a client
• Construct a FicheEmprunt for the client and document
• Check that:1. the system handles the exceptional case in a meaningful way2. the client and document states/statistics have not been
changed
III. Etude de cas – Préparation Tests d’intégration
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.35
Emprunter
Integration Test 3: Emprunt is authorised
• Construct a document, which is empruntable and not emprunté
• Construct a client
• Construct a FicheEmprunt for the client and document
• Check that the system handles the exceptional case in a meaningful way
• Check that:1. the tarif and duree des emprunts are as required2. the client and document states/statistics have been updated as
required
III. Etude de cas – Préparation Tests d’intégration
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.36
A) Préparation
1. Tests de validation, e.g.: Emprunter
2. Tests d’intégration, e.g.: Emprunter
3. Tests unitaires, e.g.: Document
B) Codage et Exécution
4. Tests unitaires avec Junit
5. Tests d’intégration
6. Tests de validation
Comment Tester la Médiathèque ?III. Etude de cas
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.37
Emprunter
Integration Test1 Code: Verify correct co-ordination by FicheEmprunt
III. Etude de cas –Tests d’Integration - Codage et Execution
• Construct a document, and make it Empruntable
• Construct a client
• Construct a FicheEmprunt for the client and document using a dummy mediatheque
• Check that the tarif and “duree des emprunts” values for the FicheEmprunt are as required
• Check that the client and document states have been updated correctly
We should do the same for integration tests 2 and 3
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.38
Emprunter
Integration Tests: Current Development Status
III. Etude de cas –Tests d’Integration - Codage et Execution
We need to analyze the status of each of the system classes in order to decide on an integration testing strategy concerning the coding of stubs and drivers (where required):
• Completed• Partial• Not yet
implemented
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.39
Emprunter
Integration Test 1
III. Etude de cas –Tests d’Integration - Codage et Execution
• Completed• Partial• Not yet
implemented
Analysis: it is too soon to code the integration tests as it would require extensive development of stubs and drivers
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.40
A) Préparation
1. Tests de validation, e.g.: Emprunter
2. Tests d’intégration, e.g.: Emprunter
3. Tests unitaires, e.g.: Document
B) Codage et Exécution4. Tests unitaires avec JUnit5. Tests d’intégration6. Tests de validation
Comment Tester la Médiathèque ?
III. Etude de cas
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.41
We will use the following UML diagrams to « derive » our unit tests for the Document class:
• Class Diagrams• State machine diagrams
We may also need to use the original natural language text.
We should not have to examine the Java code Document.java, but can just call the code using the Document.class file – this is blackbox testing.
We may need access to the documentation for the code in order to understand code properties that are not specified in the UML models.
NOTE: If documentation is poor then we will have to examine the code in order to be able to guarantee that our tests compile and execute correctly.
III. Etude de cas – Préparation Tests Unitaires
The Document class
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.42
The high-level class diagram can be partitioned so that we abstract away from the classes that are not directly « connected » to the Document
The Document class
III. Etude de cas – Préparation Tests Unitaires
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.43
We test only the public attributes and operations/methods – following the blackbox approach
We should first examine the safety invariant … if it is not in the UML model then we need to add it.
The Document classIII. Etude de cas – Préparation Tests Unitaires
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.44
The invariant property is defined on the attributes of the class in order to say when a Document instance/object is in a SAFE state, i.e. a state which is meaningful/allowable.
Here, the invariant should « include »:Emprunté => empruntableAND nbEmprunts >=0
We should link this (invariant) requirement to the original text, where possible:« La médiathèque contient un certain nombre de documents disponibles à la consultation ou à l’emprunt »
A formal interpretation that needs validation with the client
The Document classIII. Etude de cas – Préparation Tests Unitaires
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.45
BUT, these are not public
So we have a test design choice –
1) extend the Document class by adding a public invariant method:• (a) creating a new subclass (and make variables protected), or• (b) editing/updating the Document class
OR
2) use public methods – directly in the testing code - that are equivalent to testing the invariant and are guaranteed not to change the state of the object (Document) being tested (e.g. estEmpruntable and estEmprunte.)
The Document classIII. Etude de cas – Préparation Tests Unitaires
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.46
All design decisions involve compromise.
QUESTION: Can you see the advantages/disadvantages of each option for specifying the invariant property?
In this example, we choose to pursue option 1 (b) - Edit the Document class, because -
• It is good practice in OO development to have invariants specified for all classes, and
• It is the « simplest » coding option for « Java beginners »
The Document classIII. Etude de cas – Préparation Tests Unitaires
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.47
Now, let’s consider the dynamic behaviour specified by the state machine. The first thing is that the initial state (constructed) must be SAFE. Then we check that all subsequent states are SAFE.
DocumentIII. Etude de cas – Préparation Tests Unitaires
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.48
Test1: check that the construction of a Document respects the invariant
1. Create a DocumentTest class with a single main method for testing a concrete instance of a Document subclass –
• Video, • Audio, • Livre
2. Create a test method that gets called in the main method.3. Ensure that the test can be checked –
• output results to screen• print results to file• include test oracle code that knows what the results should be and
asserts these when the test executes, automating the test process
DocumentIII. Etude de cas – Préparation Tests Unitaires
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.49
Test 2: Check all reachable states to be SAFE, i.e. respect the invariant
Code Design:Complete state coverage can be achieved by a single trace of events/operations/method calls after creation –metEmpruntable()emprunter()
NOTE: Testing all states respect the invariant does not check the correct temporal behaviour of the Document class …We will see this problem later with Test4
DocumentIII. Etude de cas – Préparation Tests Unitaires
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.50
Document
We need to write at least one test for each public operation/method of the Document class.
For conciseness, we illustrate this by looking at the single Emprunter operation« emprunter : … Pour tous les documents, les statistiques sont mises à jour à savoir : le nombre d’emprunts de ce document, le nombre d’emprunts de ce type de document et le nombre d’emprunts total »
Test3 - check statistics are updated correctly
Code design steps: « emprunt » a document 5 times and, each time, check that the individual document « statistiques » are incremented. At the end of the loop, check that the total « statistiques » have increased by 5.
III. Etude de cas – Préparation Tests Unitaires
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.51
DocumentIII. Etude de cas – Préparation Tests Unitaires
Test4: correct temporal sequencing
1. Check that we can only « restituer » a document after it has been « emprunté »
2. Check that we can only « mettre en consultation » if the document is « empruntable »
Code Design: such sequences of events should produce exceptions
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.52
Document
After testing all other important temporal properties of the Document class, we should conclude the Document unit tests by testing how the constructor method(s) behaves when one tries to construct a Document using « invalid » component parameters. For example:
• Null Genre or Localisation or …• UNSAFE Genre or Localisation or …
Final Test Java (code) design steps:
1. Attempt to construct a Document with a null Genre2. Check that the exception is generated and handled as required
III. Etude de cas – Préparation Tests Unitaires
Final Test
Note: some testers chose to do this test first
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.53
A) Préparation
1. Tests de validation, e.g.: Emprunter
2. Tests d’intégration, e.g.: Emprunter
3. Tests unitaires, e.g.: Document
B) Codage et Exécution
4. Tests unitaires avec Junit
5. Tests d’intégration6. Tests de validation
Comment Tester la Médiathèque ? III. Etude de cas
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.54
Coding step - Write code for invariant in Document
public boolean invariant (){return !(emprunte && !empruntable) && nbEmprunts >=0;
DocumentIII. Etude de cas –Tests Unitaires - Codage et Execution Avec JUnit
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.55
Coding step : Update all Document operations/methods that may change state of a Document to check invariant and throw exception when it is broken.
public void metEmpruntable() throws InvariantBroken{empruntable = true;if (!invariant()) throw new InvariantBroken("Document -"+this); }
DocumentIII. Etude de cas –Tests Unitaires - Codage et Execution Avec JUnit
Mediatheque – metEmpruntable, metConsultable
Audio – emprunterLivre – emprunterVideo - emprunterFor example,
metEmpruntable:
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.56
Coding step - Update toString method to display if Document is SAFE or UNSAFE (depending on whether invariant is respected)
public String toString() { String s = "\"" + code + "\" " + titre + " " + auteur + " " + annee + " " + genre + " " + localisation + " " + nbEmprunts;if (empruntable) { s += " (emp "; if (emprunte) s += "O"; else s += "N"; s += ")"; } if (invariant()) s += " SAFE "; else s +=" UNSAFE ";return s; }
DocumentIII. Etude de cas –Tests Unitaires - Codage et Execution Avec JUnit
Note: now we need to add code for the unit tests (with JUnit). The additional invariant code will be useful in writing these tests.
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.57
Using JUnit tool – assertions and failures (see http://junit.org/javadoc/4.10/)
assertTrue(boolean)assertFalse(boolean)assertArrayEquals( _ , _ )assertEquals( _ , _ )assertNull(_)assertSame( _ , _ )fail()fail(java.lang.String )...
III. Etude de cas –Tests Unitaires - Codage et Execution Avec JUnit
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.58
Documentpackage mediatheque.document;
import static org.junit.Assert.*;import org.junit.After;import org.junit.Before;import org.junit.Test;
import mediatheque.Genre;import mediatheque.Localisation;import mediatheque.OperationImpossible;import util.InvariantBroken;
public class JUnit_Document {
protected Localisation l;protected Genre g; protected Document d1;
// setUP method Annotation @Before// tearDown method Annotation @After// test methods Annotation @Test}
III. Etude de cas –Tests Unitaires- Codage et Execution Avec JUnit
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.59
The call sequence for a class with two test methods – test1 and test2 is:
Call @Before setUpCall @Test method test1Call @After tearDownCall @Before setUpCall @Test method test2Call @After tearDown
III. Etude de cas –Tests Unitaires - Codage et Execution Avec JUnit
Call Sequences : Simplest Case
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.60
When setting up and tearing down is “expensive” then we can use @BeforeClass and @AfterClass annotations/methods to ensure that these are executed only once for each class.
For example, the call sequence for a class with two test methods – test1 and test2 is:
Call @BeforeClass setUpClassCall @Test method test1Call @Test method test2Call @AfterClass tearDownClass
III. Etude de cas –Tests Unitaires - Codage et Execution Avec JUnit
Call Sequences : More Complex Case
Note: we use the simplest case in the following examples
(See the JUnit documentation for more details on call sequences when we mix simple and complex cases)
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.61
DocumentIII. Etude de cas –Tests Unitaires - Codage et Execution Avec JUnit
@Beforepublic void setUp() throws Exception{ g = new Genre("Test_nom1"); l = new Localisation("Test_salle1","Test_rayon1"); d1 = new Video ("Test_code1", l, "Test_titre1", "Test-auteur1", "Test-annee1", g, "Test_duree1", "Test-mentionLegale1");}
@Afterpublic void tearDown() throws Exception {l=null; g=null; d1=null;}
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.62
Test1: check the construction of a Document respects the invariantDocumentIII. Etude de cas –Tests Unitaires - Codage et Execution Avec JUnit
@Testpublic void constructorInvariant( ) throws OperationImpossible, InvariantBroken{
assertTrue(d1.invariant());
}
Test2: Check all reachable states to be SAFE, i.e. respect the invariant
@Testpublic void reachableStates () throws OperationImpossible, InvariantBroken {assertTrue(d1.invariant());d1.metEmpruntable();assertTrue(d1.invariant());d1.emprunter();assertTrue(d1.invariant());}
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.63
DocumentIII. Etude de cas –Tests Unitaires - Codage et Execution Avec JUnit
Test4.1 : Check that we can only « restituer » a document after it has been « emprunté »
@Test(expected=OperationImpossible.class)public void restituerBeforeEmprunter () throws OperationImpossible, InvariantBroken {
Assert.assertTrue(d1.invariant());Assert.assertTrue(!d1.estEmprunte());d1.restituer();
}
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.64
DocumentIII. Etude de cas –Tests Unitaires - Codage et Execution Avec JUnit
Test4.1 : Check that we can only « restituer » a document after it has been « emprunté »
JUnit shows us if an expected exception was not thrown
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.65
DocumentIII. Etude de cas –Tests Unitaires - Codage et Execution Avec JUnit
Test4.1 : Check that we can only « restituer » a document after it has been « emprunté »
Q: How to Fix This
OPTION 1: Update UML diagram with new transition(s)
OPTION 2: Update Document code
OPTION 3 … : Can You Think Of Any Other Options?
Q: restituer in states consultable and empruntable?
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.66
DocumentIII. Etude de cas –Tests Unitaires - Codage et Execution Avec JUnit
Test4.1 : Check that we can only « restituer » a document after it has been « emprunté »
OPTION 1: Update UML diagram with new transition(s)
restituer
restituer
No longer require an exception to be thrown in consultable andempruntable states when restituer is called
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.67
DocumentIII. Etude de cas –Tests Unitaires - Codage et Execution Avec JUnit
Test4.1 : Check that we can only « restituer » a document after it has been « emprunté »
OPTION 2: Update Document code
public void restituer() throws InvariantBroken, OperationImpossible{
if (!emprunte) throw new OperationImpossible("Document -"+this);
emprunte = false;System.out.println("Document: ranger \"" + titre + "\" en " +localisation);if (!invariant()) throw new InvariantBroken("Document -"+this);}
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.68
Le cycle en V (terminé)
Spécification
Conception préliminaire
Conception détaillée
Codage (système et tests)
Tests unitaires
Tests d’intégration
Validationpréparation
préparation
préparation
Codage et exécution
Codage etexécution
Codage et exécution
III. Etude de cas
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.69
INHERITANCE
Inheritance complicates the testing process:
• Should we also have a test inheritance hierarchy?
• How do we test the subclassing relationship?
SOME MORE ADVANCED ISSUES
EXCEPTIONS
Exceptions complicate the testing process:
• Exception handling testing requires generating the exceptions and where/how this should be done is not always obvious
GUIs are difficult to test as you often need to simulate user actions
2013/2014 Dr J Paul Gibson, TSP, Evry CSC4002-Tests.70
To Come (In the TP)
Unit Tests – Document
Integration Tests – FicheEmprunt
Complete the validation tests : use case emprunter document
Unit tests on Document subclasses (using inheritance)