Tests d’intégration
1
mercredi 21 octobre 15
Bibliographie➡Programmation par les tests, ESIREM, Céline ROUDET
➡Comment écrire du code testable, Conférence Agile France 2010, Florence CHABANOIS
➡Reflexion on Software Quality and Maintenance, Alexandre Bergel, Chili
➡An Introduction to Test-Driven Development (TDD), Craig Murphy
➡Tests et Validation du logiciel, http://home.nordnet.fr/~ericleleu
➡Test à partir de modèles : pistes pour le test unitaire de composant, le test d'intégration et le test système, Yves Letraon
➡Les tests en orienté objet, J. Paul Gibson http://www-inf.int-evry.fr/cours/CSC4002/Documents
➡Mocks and Stubs, Martin Fowler
➡Introduction au test du logiciel, Premiers pas avec JUnit, Mirabelle Nebut
➡Écrire du code testable Par Aurélien Bompard
2
mercredi 21 octobre 15
Tests d'intégration✓Différents modules d'une application peuvent fonctionner unitairement, leur intégration, entre eux ou avec des services tiers, peut engendrer des dysfonctionnements.
✓Il est souvent impossible de réaliser les tests unitaires dans l'environnement cible avec la totalité des modules à disposition.
➡Les tests d'intégration ont pour objectif de créer une version complète et cohérente du logiciel (avec l'intégralité des modules testés unitairement) et de garantir sa bonne exécution dans l'environnement cible.
3
mercredi 21 octobre 15
Tests d’intégration
4
ObjectifVérifier les interactions entre composants unitaires
Difficultés principales de l’intégration - Interfaces floues
- Implantation non conforme à la spécification - Réutilisation de composants
1) modéliser la structure de dépendances entre chaque composant et son environnement (graphe de dépendance des tests)
2) Choisir un ordre pour intégrer (assembler)
mercredi 21 octobre 15
Graphe de dépendance : construction
A
B
A
B
association
A
B
composition
A
B
aggregation
A
B
navigability dependency
A
B
A
C
B
association class
A
B
Interfaces
Interface Name A
B
A
B
inheritance
A BC
5
mercredi 21 octobre 15
C
Céline ROUDET 67
Compilateur GNU pour Eiffel :
Graphe de dépendanceDiagramme UML
Programmation par les tests 6
mercredi 21 octobre 15
Test d’intégration : les interdépendances
➡Une solution simple consiste à contraindre le concepteur - pas de boucle dans l’architecture
‣ c’est souvent possible ‣ mais les optimisations locales ne sont pas toujours optimales globalement‣ mais concevoir des composants interdépendants est souvent naturel
7
mercredi 21 octobre 15
La communication de ce document est soumise à autorisation de la R&D de France Télécom D - 08/02/11
France TélécomRecherche & Développement
Bouchon de testØ Bouchon : une unité qui simule le
comportement d’une unité
A
BC
CFC
8mercredi 21 octobre 15
La communication de ce document est soumise à autorisation de la R&D de France Télécom D - 08/02/11
France TélécomRecherche & Développement
Bouchon de testØ Bouchon : une unité qui simule le
comportement d’une unité
A
BC
CFC
A
BC
CA
CB
Bouchon spécifique
8mercredi 21 octobre 15
Tests d’intégration ➡Architecture des dépendances
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.
9
mercredi 21 octobre 15
Tests d’intégration
Unité à testerDépendance à
tester
➡Architecture des dépendances
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.
9
mercredi 21 octobre 15
Stratégies
➡ Big-bang : tout est testé ensemble (peu recommandé)➡Top-down (peu courant)➡Bottom-up (la plus classique)
10
mercredi 21 octobre 15
Intégration - Big-Bang➡Big Bang – Validation du système –
11
http://emmanuelchenu.blogspot.com/
mercredi 21 octobre 15
Intégration - Big-Bang
12
Tests à l’interface du système
Principaux Problèmes: • Les tests produisent des erreurs : Quelle en est la cause? • La complexité induit des tests manquants • Les tests ne commencent que lorsque tous les composants ont été «codés».
Intégration de tous les composants à tester en une seule
étape. (intégration massive)
Usage Model testing
mercredi 21 octobre 15
Approche descendante
13
Unité à tester
Dépendance à tester
48mercredi 21 octobre 15
Approche descendante
13
Unité à tester
Dépendance à tester
Dépendance sous test
Unité sous test
48mercredi 21 octobre 15
Approche descendante
13
Unité à tester
Dépendance à tester
Dépendance sous test
Unité sous test
Bouchon de test (stub)
Dépendance simulée
48mercredi 21 octobre 15
Approche descendante
13
Unité à tester
Dépendance à tester
Dépendance sous test
Unité sous test
Bouchon de test (stub)
Dépendance simulée
Unité testée
Dépendance testée
48mercredi 21 octobre 15
Approche descendante
13
Unité à tester
Dépendance à tester
Dépendance sous test
Unité sous test
Bouchon de test (stub)
Dépendance simulée
Unité testée
Dépendance testée
48mercredi 21 octobre 15
Approche descendante➡Création de bouchons➡Test tardif des couches basses➡Détection précoce des défauts d'architecture
➡Effort important de simulation des composants absents et multiplie le risque d’erreurs lors du remplacement des bouchons.➡La simulation par « couches » n’est pas obligatoire
14
mercredi 21 octobre 15
Approche Ascendante
15
Unité à tester
Dépendance à tester
mercredi 21 octobre 15
Approche Ascendante
15
Unité à tester
Dépendance à tester
Lanceur
mercredi 21 octobre 15
Approche Ascendante
15
Unité à tester
Dépendance à tester
Lanceur
Unité testée
mercredi 21 octobre 15
Approche Ascendante
15
Unité à tester
Dépendance à tester
Lanceur
Unité testée
Dépendance sous test
mercredi 21 octobre 15
Approche Ascendante
15
Unité à tester
Dépendance à tester
Lanceur
Unité testée
Dépendance sous test
Dépendance testée
mercredi 21 octobre 15
Approche Ascendante
15
Unité à tester
Dépendance à tester
Lanceur
Unité testée
Dépendance sous test
Dépendance testée
mercredi 21 octobre 15
Approche ascendante
➡Avantages- Faible effort de simulation- Construction progressive de l'application s'appuie sur les modules
réels. Pas de version provisoire du logiciel- Les composants de bas niveau sont les plus testés,- Définition des jeux d'essais plus aisée- Démarche est naturelle.
➡Inconvénients- Détection tardive des erreurs majeures- Planification dépendante de la disponibilité des composants
16
mercredi 21 octobre 15
Approche Mixte
➡Combinaison des approches descendante et ascendante.➡Avantages :
- Suivre le planning de développement de sorte que les premiers composants terminés soient intégrés en premier ,
- Prise en compte du risque lié à un composant de sorte que les composants les plus critiques puissent être intégrés en premier.
➡La principale difficulté d’une intégration mixte réside dans sa complexité car il faut alors gérer intelligemment sa stratégie de test afin de concilier les deux modes d’intégration : ascendante et descendante.
17
mercredi 21 octobre 15
Mocks and Stubs
d’après Martin Fowler –http://www.martinfowler.com/articles/mocksArentStubs.html
18
Légèrement incrémenté par M. Blay-Fornarino
mercredi 21 octobre 15
Example – Electronic Store
n Orders and a Warehouse
Diet Coke5
Bread3
Rice7
Sprite10
Order1: Diet Coke - 5
Order3: Sprite - 3
Order2: Diet Coke - 2
Order4: Bread - 1
19
mercredi 21 octobre 15
Example – Electronic Store
n Use Case Model
n System Sequence
20
mercredi 21 octobre 15
Diagramme de séquence (Conception)
21
mercredi 21 octobre 15
Diagramme de séquence (Conception)
22
fill(wharehouse)
mercredi 21 octobre 15
Example – Electronic Store
n Domain Model
23
mercredi 21 octobre 15
Packages & Séparation des responsabilités
24
mercredi 21 octobre 15
Example – Electronic Storepublic class Order { … public Order(String product, int i) { this.product = product; this.amount = i; this.isFilled = false; }
public void fill(Warehouse warehouse) { if (warehouse.hasInventory(product,amount)) { warehouse.remove(product,amount); isFilled = true; } }
public boolean isFilled() { return isFilled; }}
n Testing the Order class
.......
25
mercredi 21 octobre 15
Example – Electronic Store public class OrderStateTester extends TestCase { … public void testOrderIsFilledIfEnoughInWarehouse(){ Order order = new Order(DIET_COKE,5); order.fill(warehouse); // Primary object test assertTrue(order.isFilled()); // Secondary object test(s) assertEquals(0,warehouse.getInventory(DIET_COKE)); } public void testOrderDoesNotRemoveIfNotEnough(){ Order order = new Order(SPRITE,11); order.fill(warehouse); // Primary object test assertFalse(order.isFilled()); // Secondary object test(s) assertEquals(10, warehouse.getInventory(SPRITE)); }}
n Testing the Order class
26
mercredi 21 octobre 15
Example – Electronic Store
n Testing the Order class:
public class OrderStateTester extends TestCase { private static String DIET_COKE = "Diet Coke"; private static String SPRITE = "Sprite"; Warehouse warehouse; protected void setUp() throws Exception { //Fixture with secondary object(s) warehouse = new WarehouseImpl(); warehouse.add(DIET_COKE,5); warehouse.add(SPRITE,10); } …
27
mercredi 21 octobre 15
Example – Electronic Store
n Using a stub to run the tests -q Stubs return canned data to methods calls:public class WarehouseImpl implements Warehouse {
public void add(String product, int i) {}
public int getInventory(String product) { return 0; }
public boolean hasInventory(String product) { return false; }
public void remove(String product, int i) { }}
Stub
28
mercredi 21 octobre 15
29
mercredi 21 octobre 15
Example – Electronic Store
n The tests fail since the stub object – warehouse (secondary) misses the required functionality
n Remember: the intension is to test the behavior of the primary object - Order, all other objects are tested in their own corresponding tests.
n The test is only State-Basedq E.g., was the remove() method invoked? Other
methods of the warehouse object?30
mercredi 21 octobre 15
Example – Electronic Store
n State Based tests:q All objects involved must be created – complex fixtureq After the primary object was “kicked” with the behavior that
is being tested, the result is evaluated against:n The primary objectn All secondary objects
q If the test fails, its source might be fuzzy between the primary and the secondary objects
q No interaction is being tested!n A possible solution – Mock objects
Before After
31
mercredi 21 octobre 15
Example – Electronic Storen Tests basés sur les interactions
q Les tests doivent vérifier quelles méthodes ont été appelées sur les objets secondaires.
q Tous les objets secondaires sont remplacés par des «mocks»q => spécification des interfaces des objets secondairesq Test en Isolation: Les Bugs détectés dans les tests sont
uniquement liés aux objets primaires
q Fortement couplés avec la mise en œuvre => peuvent interférer avec la refactorisation
32
mercredi 21 octobre 15
Using EasyMock
n Define only the interface of the Mock object:
public interface Warehouse {
void add(String product, int i); int getInventory(String product); boolean hasInventory(String product,int amount); void remove(String product, int i);}
33
mercredi 21 octobre 15
Using EasyMock
n Create the Mock object:
protected void setUp() throws Exception { //Fixture with secondary object(s) mock = createMock(Warehouse.class); }
34
n Add the EasyMock jar file (easymock.jar) from this directory to your classpath
n import static org.easymock.EasyMock.*;
You need to :
mercredi 21 octobre 15
Using EasyMock
n Running tests with expectations: public void testOrderIsFilledIfEnoughInWarehouse(){ //Expectations expect(mock.hasInventory(DIET_COKE,5)).andReturn(true); mock.remove(DIET_COKE,5); replay(mock); Order order = new Order(DIET_COKE,5); order.fill(mock); // Primary object test assertTrue(order.isFilled());
// Secondary object test(s) verify(mock); }
35
public void fill(Warehouse warehouse) {if (warehouse.hasInventory(product,amount)) {
warehouse.remove(product,amount)isFilled = true;
mercredi 21 octobre 15
Using EasyMock
n Verifying Behaviorq If the method is not called on the Mock Object
public void testDemo(){ mock.remove("cola",2); replay(mock); verify(mock); }
java.lang.AssertionError: Expectation failure on verify: remove("cola", 2): expected: 1, actual: 0
36
mercredi 21 octobre 15
Using EasyMock
n Verifying Behaviorq If the method is not called on the Mock Object
public void testDemo(){ mock.remove("cola",2); replay(mock); Order order = new Order(SPRITE,11); order.fill(mock); verify(mock); }
java.lang.AssertionError: Unexpected method call hasInventory("Sprite", 11): remove("cola", 2): expected: 1, actual: 0
37
mercredi 21 octobre 15
"I have not failed, I've just found ten thousand ways that won't work." – Thomas Edison
38
mercredi 21 octobre 15
Tests d’intégration : préparation
39
L’opération d’emprunter requière une coordination entre les objets : client, médiathèque, document et
ficheEmprunt.
On veut vérifier les traces de communications.Ces tests peuvent être déduits des diagrammes de
séquences.
http://www-inf.it-sudparis.eu/cours/CSC4002/Documents/tests-mediatheque-1pp.pdf
mercredi 21 octobre 15
40http://www-inf.it-sudparis.eu/cours/CSC4002/
Documents/tests-mediatheque-1pp.pdfmercredi 21 octobre 15
Integration Test1 : emprunter➡ Un « emprunt » n’est pas autorisé parce que le document n’est pas 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 way‣2. the client and document states/statistics have not been changed
41
http://www-inf.it-sudparis.eu/cours/CSC4002/Documents/tests-mediatheque-1pp.pdf
mercredi 21 octobre 15
Integration Test2 : emprunter
➡Un « emprunt » n’est pas autorisé parce que le document est « 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 way‣2.the client and document states/statistics have not been changed
42
http://www-inf.it-sudparis.eu/cours/CSC4002/Documents/tests-mediatheque-1pp.pdf
mercredi 21 octobre 15
Integration Test3 : 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 using a dummy mediatheque
- Check that:‣1. the tarif and duree des emprunts are as required‣2. the client and document states/statistics have been updated as required
43
http://www-inf.it-sudparis.eu/cours/CSC4002/Documents/tests-mediatheque-1pp.pdf
Verify correct co-ordination by FicheEmprunt
mercredi 21 octobre 15
Integration Test3 : emprunterpublic class IntegrationTest {
! Genre g;! Localisation l;! Document d1;! CategorieClient cat;! Client c1;! @Before! public 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, 120, "Test_mentionLegale1");! ! cat = new CategorieClient("TarifReduit", 4, 25.0, 1.0, 1.0, true);! ! c1 = new Client("nom1", "prenom1", "adresse1", cat, 0);! }! @After! public void tearDown() throws Exception {! ! l = null;! ! g = null;! ! d1 = null;! ! cat = null;! ! c1 = null;! }
44
http://www-inf.it-sudparis.eu/cours/CSC4002/Documents/tests-mediatheque-1pp.pdf
mercredi 21 octobre 15
Integration Test3 : emprunter! @Test! public void creationFicheEmpruntDocEmpruntable()! ! ! throws OperationImpossible, InvariantBroken {! ! // INTEGRATION TEST 3 - Emprunter - Verify correct co-ordination by! ! // FicheEmprunt! ! d1.metEmpruntable();! ! FicheEmprunt f1 = new FicheEmprunt(c1, d1);! ! // check that the client, document and genre states have been updated correctly! ! Assert.assertEquals(1, d1.getNbEmprunts());! ! Assert.assertEquals(1, c1.getNbEmpruntsEffectues());! ! Assert.assertEquals(1, g.getNbEmprunts());! ! // check that the duration and paiement information are ok! ! Assert.assertTrue(f1.getDureeEmprunt() == 14);! ! Assert.assertTrue( f1.getTarifEmprunt() == 1.5);! }
45
http://www-inf.it-sudparis.eu/cours/CSC4002/Documents/tests-mediatheque-1pp.pdf
mercredi 21 octobre 15
Integration Test3 : emprunter
! @Test(expected = OperationImpossible.class)! public void creationFicheEmpruntDocNonEmpruntable()! ! ! throws OperationImpossible, InvariantBroken {! ! // INTEGRATION TEST 1 - Emprunter - co-ordination when Document not! ! // empruntable! ! new FicheEmprunt(c1, d1);! }
46
http://www-inf.it-sudparis.eu/cours/CSC4002/Documents/tests-mediatheque-1pp.pdf
mercredi 21 octobre 15
Integration Tests: Typical/Example Development Status
47
http://www-inf.it-sudparis.eu/cours/CSC4002/Documents/tests-
mediatheque-1pp.pdf
mercredi 21 octobre 15
Top Related