Tests

 orientés  objets  
Mocking  -­‐  Mockito  

 
 

Philippe  Collet  
 
L3  MIAGE  
2014-­‐2015  

P. Collet 1
 Plan  

•  Mocking  
•  Mockito  

P. Collet 2
 Défini@on  
•  Mock  =  Objet  fac@ce  
•  les  mocks  (ou  Mock  object)  sont  des  objets  
simulés  qui  reproduisent  le  comportement  
d'objets  réels  de  manière  contrôlée  
•  On  teste  ainsi  le  comportement  d'autres  
objets,  réels,  mais  liés  à  un  objet  inaccessible  
ou  non  implémenté  
•  Cet  objet  est  remplacé  par  un  mock  

P. Collet 3
 Défini@on(s)  
•  dummy  (pan@n,  fac@ce)  :  objets  vides  qui  n'ont  
pas  de  fonc@onnalités  implémentées  
•  stub  (bouchon)  :  classes  qui  renvoient  en  dur  une  
valeur  pour  une  méthode  invoquée  
•  fake  (subs@tut,  simulateur)  :  implémenta@on  
par@elle  qui  renvoit  toujours  les  mêmes  réponses  
selon  les  paramètres  fournis  
•  spy  (espion)  :  classe  qui  vérifie  l'u@lisa@on  qui  en  
est  faite  après  l'exécu@on  
•  mock  (fac@ce)  :  classes  qui  agissent  comme  un  
stub  et  un  spy  
P. Collet 4
 Exemple  d’u@lisa@on  
•  Comportement  non  déterministe  (l'heure,  un  
senseur)  
•  Ini@alisa@on  longue  (BD)  
•  Classe  pas  encore  implémentée  ou  
implémenta@on  changeante,  en  cours  
•  Etats  complexes  difficiles  à  reproduire  dans  les  
tests  (erreur  réseau,  excep@on  sur  fichiers)  
•  Pour  tester,  il  faudrait  ajouter  des  a[ribut  ou  des  
méthodes  

P. Collet 5
 Principe  
•  Un  mock  a  la  même  interface  que  l'objet  qu'il  
simule  
•  L'objet  client  ignore  s'il  interagit  avec  un  objet  
réel  ou  un  objet  simulé  
•  La  plupart  des  frameworks  de  mock  
perme[ent    
–  De  spécifier  quelles  méthodes  vont  être  appelées,  
avec  quels  paramètres  et  dans  quel  ordre  
–  De  spécifier  les  les  valeurs  retournées  par  le  mock    

P. Collet 6
 Mockito  

h[p://code.google.com/p/mockito/  
 
Eléments  de  cours  de  M.  Nebut  lifl.fr    

P. Collet 7
 Mockito  
•  Générateur  automa@que  de  doublures  
•  Léger  
–  Focalisa@on  sur  le  comportement  recherché  et  la  
vérifica@on  après  l’exécu@on  
•  Simple  
–  Un  seul  type  de  mock  
–  Une  seule  manière  de  les  créer  
 

P. Collet
 Principes  
•  Fonc@onnement  en  mode  espion  (spy)  :  
–  Créa@on  des  mocks  
•  méthode  mock  ou  annota@on  @mock  
–  Descrip@on  de  leur  comportement  
•  Méthode  when  
–  Mémorisa@on  à  l’exécu@on  des  interac@ons  
•  U@lisa@on  du  mock  dans  un  code  qui  teste  un  
comportement  spécifique  
–  Interroga@on,  à  la  fin  du  test,  des  mocks  pour  savoir  
comme  ils  ont  été  u@lisés  
•  Méthode  verify  
import static org.mockito.Mockito.*
P. Collet
 Créa@on  
•  Par  une  interface  ou  une  classe  (u@lisa@on  de  .class)  
–  UneInterface  mockSansNom  =  mock(UneInterface.class);  
–  UneInterface  mockAvecNom  =  
                               mock(UneInterface.class,  "ceMock");  
–  @Mock  UneInterface  ceMock;    
•  Comportements  par  défaut  
–  assertEquals("ceMock",  monMock.toString());    
–  assertEquals("type  numerique  :  0  ",  0,  
             monMock.retourneUnEn@er());    
–  assertEquals("type  booleéen  :  false",  
                                                     false,  monMock.retourneUnBooleen());  
–  assertEquals("type  collec@on  :  vide",  
                                                   0,  monMock.retourneUneList().size());  

P. Collet 10
 Stubbing  
•  Pour  remplacer  le  comportement  par  défaut  
des  méthodes  
•  Deux  possibilités  
–  Méthode  qui  a  un  type  de  retour  :    
•  when  +  thenReturn  ;  
•  when  +  thenThrow  ;  
–  Méthode  de  type  void  :    
•  doThrow  +  when  ;  

P. Collet 11
 Stubbing  
retour  d’une  valeur  unique  

// stubbing
when(monMock.retourneUnEntier()).thenReturn(3);

// description avec JUnit

assertEquals("une premiere fois 3", 3, monMock.retourneUnEntier());
assertEquals("une deuxieme fois 3", 3, monMock.retourneUnEntier());

P. Collet 12
 Stubbing  
valeurs  de  retour  consécu@ves  

// stubbing
when(monMock.retourneUnEntier()).thenReturn(3, 4, 5);

// description avec JUnit

assertEquals("une premiere fois : 3", 3, monMock.retourneUnEntier());
assertEquals("une deuxieme fois : 4", 4, monMock.retourneUnEntier());
assertEquals("une troisieme fois : 5", 5, monMock.retourneUnEntier());

when(monMock.retourneUnEntier()).thenReturn(3, 4);
// raccourci pour .thenReturn(3).thenReturn(4);

P. Collet 13
 Stubbing  
Levée  d’excep@ons  
public int retourneUnEntierOuLeveUneExc() throws BidonException;
// stubbing
when(monMock.retourneUnEntierOuLeveUneExc()).thenReturn(3)
.thenThrow(new BidonException());

// description avec JUnit

assertEquals("1er appel : retour 3",
3, monMock.retourneUnEntierOuLeveUneExc());

try {
monMock.retourneUnEntierOuLeveUneExc(); fail();
} catch (BidonException e) {
assertTrue("2nd appel : exception", true);
}
Levée d’exception + méthode void = doThrow
P. Collet 14
 Remarques  
•  Les  méthodes  equals()  et  hashcode()  ne  peuvent  
pas  être  stubbées  
•  Un  comportement  de  mock  non  exécuté  ne  
provoque  pas  d’erreur  
•  Il  faut  u@liser  verify  
–  Quelles  méthodes  ont  été  appelées  sur  un    
–  Combiendefois,  avec  quels  paramètres,  dans  quel  
ordre  
•  Une  excep@on  est  levée  si  la  vérifica@on  échoue,  
le  test  échouera  aussi  
P. Collet 15
 Verify  
•  Méthode  appelée  une  seule  fois  :    
–  verify(monMock).retourneUnBooleen();  
–  verify(monMock,  @mes(1)).retourneUnBooleen();    
•  Méthode  appelée  au  moins/au  plus  une  fois:  
–  verify(monMock,  atLeastOnce()).retourneUnBooleen();    
–  verify(monMock,  atMost(1)).retourneUnBooleen();  
•  Méthode  jamais  appelée  :    
–  verify(monMock,  never()).retourneUnBooleen();    
•  Avec  des  paramètres  spécifiques  :  
–  verify(monMock).retourneUnEn@erBis(4,  2);    

P. Collet 16
 Verify  
•  import  org.mockito.InOrder;    
•  Pour  vérifier  que  l’appel  (4,2)  est  effectué  avant  
l’appel  (5,3)  :    
–  InOrder  ordre  =  inOrder(monMock);    
–  ordre.verify(monMock).retourneUnEn@erBis(4,  2);    
–  ordre.verify(monMock).retourneUnEn@erBis(5,  3);  
•  Avec  plusieurs  mocks  :    
–  InOrder  ordre  =  inOrder(mock1,  mock2);  
–  ordre.verify(mock1).foo();    
–  ordre.verify(mock2).bar();    

P. Collet 17
 Espionner  un  objet  classique  
•  Pour  espionner  autre  chose  qu’un  objet  mock  (un  
objet  «  réel  »):  
–  Obtenir  un  objet  espionné  par  la  méthode  spy  :  
List  list  =  new  LinkedList();  
List  spy  =  spy(list);  
–  Appeler  des  méthodes  «  normales  »  sur  le  spy  :  
spy.add("one");  
spy.add("two");  
–  Vérifier  les  appels  à  la  fin  :  
verify(spy).add("one");  
verify(spy).add("two");  

P. Collet 18
 Matchers  

•  Mockito  vérifie  les  valeurs  en  arguments  en  u@lisant  equals()  

•  Assez  souvent,  on  veut  spécifier  un  appel  dans  un  «  when  »  ou  un  
«  verify  »  sans  que  les  valeurs  des  paramètres  aient  vraiment  
d’importance  

•  On  u@lise  pour  cela  des  Matchers  (import  org.mockito.Matchers)  

 
–  when(mockedList.get(anyInt())).thenReturn("element");  
 
–  verify(mockedList).get(anyInt());  

P. Collet 19
 Matchers  
•  Les  Matchers  très  souvent  u@lisés  :  
–  any()  ,  sta@c  <T>  T  anyObject()    
–  anyBoolean(),  anyDouble(),  anyFloat()  ,  anyInt(),  anyString()…  
–  anyList(),  anyMap(),  anyCollec@on(),  
anyCollec@onOf(java.lang.Class<T>  clazz)  ,anySet(),  <T>  
[email protected]<T>  anySetOf(java.lang.Class<T>  clazz)  
–  …  
 
•  A[en@on  !  Si  on  u@lise  des  matchers,  tous  les  arguments  
doivent  être  des  matchers  :  
–  verify(mock).someMethod(anyInt(),  anyString(),  "third  
argument");  
–  n’est  pas  correct  !  

P. Collet 20
 Alterna@ves  à  Mockito  
•  EasyMock,  Jmock  
•  Tous  basés  sur  expect-­‐run-­‐verify  

P. Collet 21
P. Collet 22