[PDF] Mocks and Stubs 18 sept. 2013 complète

View - Download Mocks and Stubs

Previous PDF

Next PDF

Tests dÕintŽgration

1 mercredi 18 septembre 13

Tests d'intŽgration

n DiffŽrents modules d'une application peuvent fonctionner unitairement, leur intŽgration, entre eux ou avec des services tiers, peut engendrer des dysfonctionnements. n Il est souvent impossible de rŽaliser les tests unitaires dans l'environnement cible avec la totalitŽ des modules ˆ disposition. n Les tests d'intŽgration ont pour objectif de crŽer une version testŽs unitairement) et de garantir sa bonne exŽcution dans l'environnement cible. 2 mercredi 18 septembre 13 iut informatique, Nice

Tests dÕintŽgration

3

Objectif

VŽriÞer les interactions entre composants unitaires DifÞcultŽs principales de lÕintŽgration - Interfaces ßoues - Implantation non conforme ˆ la spŽciÞcation - 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 18 septembre 13 iut informatique, Nice

Graphe de dŽpendance : construction

AB ABassociationABcompositionABaggregationABnavigabilitydependencyABACBassociation classABInterfaces

Interface Name

AB

ABinheritance

ABC 4 mercredi 18 septembre 13 C

CŽline ROUDET67

Compilateur GNU pour Eiffel :

Graphe de dŽpendanceDiagramme UML

Programmation par les tests5

mercredi 18 septembre 13 iut informatique, Nice

Test dÕintŽgration : les

interdŽpendances n Une solution simple consiste ˆ contraindre le concepteur - pas de boucle dans lÕarchitecture q cÕest souvent possible q mais les optimisations locales ne sont pas toujours optimales globalement q mais concevoir des composants interdŽpendants est souvent naturel 6 mercredi 18 septembre 13 La communication de ce document est soumise ˆ autorisation de la R&D de France TŽlŽcom

D - 08/02/11

France TŽlŽcom

Recherche & DŽveloppement

Bouchon de test

n

Bouchon : une unitŽ qui simule le

comportement dÕune unitŽ

ABCCFCABC

C A C B

Bouchon spŽcifique

7 mercredi 18 septembre 13 iut informatique, Nice

Tests dÕintŽgration

UnitŽ ˆ testerDŽpendance ˆ

tester nArchitecture des dŽpendances Note: in reality, one rarely sees a tree due to shared components and cyclic dependencies.

However, one can always Þnd a reasonable tree

abstraction from any given composition hierachy. 8 mercredi 18 septembre 13 iut informatique, Nice

StratŽgies

n Big-bang : tout est testŽ ensemble (peu recommandŽ) n

Top-down (peu courant)

n

Bottom-up (la plus classique)

9 mercredi 18 septembre 13 iut informatique, Nice

IntŽgration - Big-Bang

n 10 http://emmanuelchenu.blogspot.com/ mercredi 18 septembre 13 iut informatique, Nice

IntŽgration - Big-Bang

11

Tests ˆ lÕinterface du

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

mercredi 18 septembre 13 iut informatique, Nice

Approche descendante

12

UnitŽ ˆ testerDŽpendance ˆ testerDŽpendance sous testUnitŽ sous testBouchon de test (stub)DŽpendance simulŽeUnitŽ testŽeDŽpendance testŽe

48
mercredi 18 septembre 13 iut informatique, Nice

Approche descendante

n

CrŽation de bouchons

n

Test tardif des couches basses

n DŽtection prŽcoce des dŽfauts d'architecture n

Effort important de simulation des composants

absents et multiplie le risque dÕerreurs lors du remplacement des bouchons. n

La simulation par Ç

n couches n

È nÕest pas obligatoire

13 mercredi 18 septembre 13 iut informatique, Nice

Approche Ascendante

14

UnitŽ ˆ testerDŽpendance ˆ tester

Lanceur

UnitŽ testŽeDŽpendance sous testDŽpendance testŽe mercredi 18 septembre 13 iut informatique, Nice

Approche ascendante

n

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ŽÞnition des jeux d'essais plus aisŽe -DŽmarche est naturelle. n

InconvŽnients

-DŽtection tardive des erreurs majeures -PlaniÞcation dŽpendante de la disponibilitŽ des composants 15 mercredi 18 septembre 13 iut informatique, Nice

Approche Mixte

n Combinaison des approches descendante et ascendante. n

Avantages :

-Suivre le planning de dŽveloppement de sorte que les premiers composants terminŽs soient intŽgrŽs en premier n -Prise en compte du risque liŽ ˆ un composant de sorte que les composants les plus critiques puissent tre intŽgrŽs en premier. n La principale difÞcultŽ dÕune intŽgration mixte rŽside dans sa complexitŽ car il faut alors gŽrer intelligemment sa stratŽgie de test aÞn de con cilier le s deux modes dÕintŽgration n : ascendante et descendante. 16 mercredi 18 septembre 13

Mocks and Stubs

17

M. Blay-Fornarino

mercredi 18 septembre 13

Example Ð Electronic Store

n

Orders and a Warehouse

Diet Coke

5 Bread 3 Rice 7

Sprite

10 Order1: Diet Coke - 5Order3: Sprite - 3Order2: Diet Coke - 2Order4: Bread - 118 mercredi 18 septembre 13

Example Ð Electronic Store

n

Use Case Model

n

System Sequence

19 mercredi 18 septembre 13

Diagramme de sŽquence (Conception)

20 mercredi 18 septembre 13

Diagramme de sŽquence (Conception)

21
mercredi 18 septembre 13

Example Ð Electronic Store

n

Domain Model

22
mercredi 18 septembre 13

Packages & SŽparation des

responsabilitŽs 23
mercredi 18 septembre 13

Example Ð Electronic Store

public class Order { n pu blic Order(String product, int i) { t his. product = product; t his. amount = i; t his. isFilled = false; pu blic void fill(Warehouse warehouse) { if (warehouse.hasInventory(product,amount)) { warehouse.remove(product,amount); isFi lle d = true; pu blic boolean isFilled() { re turn isFilled; n

Testing the

Order class

24
mercredi 18 septembre 13

Example Ð Electronic Store

public class OrderStateTester extends TestCase { n pu blic void testOrderIsFilledIfEnoughInWarehouse(){

O rder order = new Order(DIET_COKE,5);

orde r.fill(warehouse); // Primary object test a ssertT rue(order.isFilled()); // Secondary object test(s) a ssertEq uals(0,warehouse.getInventory(DIET_COKE)); pu blic void testOrderDoesNotRemoveIfNotEnough(){

O rder order = new Order(SPRITE,11);

o rder .fill(warehouse); // Primary object test a ssertF alse(order.isFilled()); // Secondary object test(s) a ssertEq uals(10, warehouse.getInventory(SPRITE)); n

Testing the

Order class

25
mercredi 18 septembre 13

Example Ð Electronic Store

n

Testing the Order class:

public class OrderStateTester extends TestCase { pri vate static String DIET_COKE = qDiet Cokeq; pri vate static String SPRITE = qSpriteq;

W arehouse warehouse;

pro tected void setUp() throws Exception { //Fixture with secondary object(s) ware house = new WarehouseImpl(); w areh ouse.add(DIET_COKE,5); w areh ouse.add(SPRITE,10); n 26
mercredi 18 septembre 13

Example Ð Electronic Store

n

Using a stub to run the tests -

q

Stubs return canned data to methods calls:

public class WarehouseImpl implements Warehouse { pu blic void add(String product, int i) {} pu blic int getInventory(String product) { retu rn 0; pu blic boolean hasInventory(String product) { re turn false; pu blic void remove(String product, int i) { } Stub 27
mercredi 18 septembre 13 28
mercredi 18 septembre 13

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-Based

q

E.g., was the remove() method invoked? Other

methods of the warehouse object? 29
mercredi 18 septembre 13

Example Ð Electronic Store

n

State Based tests:

q All objects involved must be created Ð complex fixture q After the primary object was ÒkickedÓ with the behavior that is being tested, the result is evaluated against: n

The primary object

n

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 testedn

n

A possible solution Ð Mock objects

BeforeAfter30

mercredi 18 septembre 13

Example Ð Electronic Store

n

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 secondaires q Test en Isolation: Les Bugs dŽtectŽs dans les tests sont uniquement liŽs aux objets primaires q avec la refactorisation 31
mercredi 18 septembre 13

Using EasyMock

n

Define only the interface of the Mock object:

public interface Warehouse { voi d add(String product, int i); in t getInventory(String product); bo olean hasInventory(String product,int amount); voi d remove(String product, int i); 32
mercredi 18 septembre 13

Using EasyMock

n

Create the Mock object:

pro tected void setUp() throws Exception { / /Fi xture with secondary object(s) mock = createMock(Warehouse.class); 33n
Add the EasyMock jar file (easymock.jar) from this directory to your classpath n import static org.easymock.EasyMock.*;

You need to :

mercredi 18 septembre 13

Using EasyMock

n

Running tests with expectations:

pu blic void testOrderIsFilledIfEnoughInWarehouse(){ //Expectations e xpect (mock.hasInventory(DIET_COKE,5)).andReturn(true); mo ck.remo ve(DIET_COKE,5); replay(mock);

O rder order = new Order(DIET_COKE,5);

order.fill(mock); / / Pri mary object test a ssertT rue(order.isFilled()); // Secondary object test(s) verify(mock); 34
public void fill(Warehouse warehouse) { if (warehouse.hasInventory(product,amount)) { warehouse.remove(product,amount) isFilled = true; mercredi 18 septembre 13

Using EasyMock

n

Verifying Behavior

q

If the method is not called on the Mock Object

pu blic void testDemo(){quotesdbs_dbs22.pdfusesText_28

[PDF] Architecture logicielle - mbf i3s

[PDF] Architecture logicielle MVC - LIG Membres

[PDF] 1 Architecture traditionnelle et réhabilitation au Maroc - RehabiMed

[PDF] Le matériel : architecture des ordinateurs - Limuniv-mrsfr

[PDF] Architecture matériel et logiciel 2

[PDF] Architectures Logicielles et Matérielles - Verimag

[PDF] Vers une architecture n-tiers

[PDF] Les réseaux Peer-to-Peer

[PDF] L 'architecture postale - La Poste

[PDF] Partie 1 : Architecture et communications Client/Serveur - Univ Lyon 1

[PDF] Architecture Traditionnelle Méditerranéenne Méthode RehabiMed

[PDF] La fabrication de l architecture en Tunisie indépendante : une

[PDF] l 'architecture traditionnelle en tunisie : l 'habitat rural - RehabiMed

[PDF] Etude d une architecture IP intégrant un lien satellite - OATAO

[PDF] Les règles de classement et d 'archivage des documents d 'entreprise