different types matchers provided mockito
com reproduir un fitxer MKV a Windows
Introducció als diferents tipus de coincidències a Mockito.
Mofes i espies a Mockito es van explicar detalladament en el nostre anterior tutorial de detallat Sèrie d'entrenament Mockito .
Què són els Matchers?
Les coincidències són com ara l’expressió regular o els comodins on, en lloc d’una entrada (i / o sortida) específica, especifiqueu un rang / tipus d’entrada / sortida en funció dels quals es poden descansar els trossos / espies i es poden verificar les trucades als trossos.
Tots els aparelladors de Mockito formen part de ‘ Mockito ' classe estàtica.
Els aparelladors són una eina poderosa que permet una forma abreujada de configurar talons, així com verificar les invocacions als talons, esmentant les entrades d’arguments com a tipus genèrics a valors específics en funció del cas d’ús o escenari.
Què aprendreu:
Tipus de coincidències a Mockito
A Mockito, a grans trets, hi ha dos tipus de coincidents o en termes d'ús, es poden utilitzar aparelladors per a les 2 categories següents:
- Argument Matchers durant la configuració de Stub
- Coincidències de verificació per verificar les trucades reals als talons
Per als dos tipus de concordança, és a dir, Argument i verificació, Mockito proporciona un conjunt enorme de concordança (clic aquí per obtenir una llista completa dels coincidents).
Coincidències d’arguments
A continuació s’enumeren els més utilitzats:
Per a tot el que es mostra a continuació, considerem provar una llista completa:
final List mockedIntList = mock(ArrayList.class);
# 1) any (): accepta qualsevol objecte (inclòs nul).
when (mockedIntList.get( any ())).thenReturn(3);
# 2) qualsevol (classe d'idioma java) -
Exemple : any (ClassUnderTest.class): es tracta d’una variant més específica de qualsevol () i només accepta objectes del tipus de classe que s’esmenten com a paràmetre de plantilla.
when (mockedIntList.get( any (Integer.class))).thenReturn(3);
# 3) anyBoolean (), anyByte (), anyInt (), anyString (), anyDouble (), anyFloat (), anyList () i molts altres: tots accepten qualsevol objecte del tipus de dades corresponent, a més de valors nuls.
when (mockedIntList.get( any Int())).thenReturn(3);
# 4) Arguments específics: en els casos en què els arguments reals es coneixen prèviament, sempre es recomana utilitzar-los, ja que proporcionen més confiança en contra dels tipus d'arguments genèrics.
Exemple:
when(mockedIntList.get(1)).thenReturn(3);
Coincidències de verificació
Hi ha alguns aparells especialitzats disponibles per esperar / afirmar coses com no. d’invocacions a la burla.
Per a tots els que apareixen a continuació, considerem la mateixa llista d’exemples que hem utilitzat abans.
final List mockedIntList = mock(ArrayList.class);
# 1) Invocacions simulades
(i) La invocació simple a Mock verifica si el mètode burlat s'ha cridat / interactuat o no configurant la mida de la llista burlada a 5.
//arrange when(mockedList.size()).thenReturn(5); // act int size = mockedList.size(); // assert verify(mockedList).size();
(ii) El recompte específic d’interaccions amb un mètode burlat verifica el recompte de núm. de vegades s'esperava que es cridés a la burla.
//arrange when(mockedList.size()).thenReturn(5); // act int size = mockedList.size(); // assert verify(mockedList, times(1)).size();
Per tal de verificar si hi ha 0 interaccions, simplement canvieu el valor d'1 a 0 com a argument per a la coincidència de times ().
//arrange when(mockedList.size()).thenReturn(5); // act int size = mockedList.size(); // assert verify(mockedList, times(0)).size();
En cas d’errors, retorna les següents excepcions:
a) Quan les invocacions esperades són inferiors a les invocacions reals:
Exemple: Buscat 2 vegades, però invocat 3 vegades, llavors Mockito torna - ' verification.TooManyActualInvocations '
Codi d'exemple:
final List mockedIntList = mock(ArrayList.class); // Arrange when(mockedIntList.get(anyInt())).thenReturn(3); // Act int response = mockedIntList.get(5); response = mockedIntList.get(3); response = mockedIntList.get(100); // Assert verify(mockedIntList, times(2)).get(anyInt());
b) Quan les invocacions esperades són més que les invocacions reals:
Exemple: Volia 2 vegades, però se’l va invocar 1 vegada, llavors Mockito torna - ' verification.TooLittleActualInvocations '
final List mockedIntList = mock(ArrayList.class); // Arrange when(mockedIntList.get(anyInt())).thenReturn(3); // Act int response = mockedIntList.get(5); response = mockedIntList.get(3); response = mockedIntList.get(100); // Assert verify(mockedIntList, times(4)).get(anyInt());
(Iii) No hi ha interaccions amb el mètode específic de l'objecte burlat.
final List mockedIntList = mock(ArrayList.class); // Arrange when(mockedIntList.get(anyInt())).thenReturn(3); // Act int response = mockedIntList.get(5); // Assert verify(mockedIntList, never()).size();
(iv) Verifiqueu l'ordre de les interaccions burlades: és especialment útil quan voleu assegurar l'ordre en què es van cridar els mètodes dels objectes burlats.
Exemple: Operacions similars a les bases de dades en què una prova hauria de verificar l’ordre en què van passar les actualitzacions de la base de dades.
Per il·lustrar-ho per exemple - Continuem amb la mateixa llista d’exemples.
Ara suposem que l’ordre de les trucades als mètodes de llista estaven en seqüència, és a dir, get (5), size (), get (2). Per tant, l’ordre de verificació també hauria de ser el mateix.
// Arrange when(mockedIntList.get(anyInt())).thenReturn(3); when(mockedIntList.size()).thenReturn(100); InOrder mockInvocationSequence = Mockito.inOrder(mockedIntList); // Act int response = mockedIntList.get(5); int size = mockedIntList.size(); response = mockedIntList.get(2); // Assert mockInvocationSequence.verify(mockedIntList, times(1)).get(anyInt()); mockInvocationSequence.verify(mockedIntList).size(); mockInvocationSequence.verify(mockedIntList, times(1)).get(anyInt());
En cas de seqüència de verificació incorrecta, Mockito llança una excepció, és a dir, ' verification.VerificationInOrderFailure '.
Per tant, a l’exemple anterior, si canvio l’ordre de verificació mitjançant l’intercanvi de les dues darreres línies, començaré a obtenir l’excepció VerificationInOrderFailure.
// Arrange when(mockedIntList.get(anyInt())).thenReturn(3); when(mockedIntList.size()).thenReturn(100); InOrder mockInvocationSequence = Mockito.inOrder(mockedIntList); // Act int response = mockedIntList.get(5); int size = mockedIntList.size(); response = mockedIntList.get(2); // Assert mockInvocationSequence.verify(mockedIntList, times(1)).get(anyInt()); mockInvocationSequence.verify(mockedIntList, times(1)).get(anyInt()); mockInvocationSequence.verify(mockedIntList).size();
(v) Verifiqueu que la interacció s'ha produït almenys / màxima de vegades.
(A) al menys:
Exemple: atleast (3): verifica que l'objecte burlat ha estat invocat / interactuat amb almenys tres vegades durant la prova. Per tant, qualsevol de les interaccions 3 o superiors a 3 hauria de fer que la verificació tingui èxit.
Pregunta i respostes de l'entrevista sql per experimentats
// Arrange when(mockedIntList.get(anyInt())).thenReturn(3); // Act int response = mockedIntList.get(5); response = mockedIntList.get(2); // Assert verify(mockedIntList, atLeast(2)).get(anyInt());
En cas d'errors, és a dir, quan les invocacions reals no coincideixen, es produeix la mateixa excepció que amb el paràmetre times () és a dir, ' verification.TooLittleActualInvocations ”
(B) atmost:
Exemple: atmost (3): verifica si l'objecte burlat s'ha invocat / interactuat amb l'atmosfera tres vegades durant la prova. Per tant, qualsevol de les interaccions 0,1,2 o 3 amb el simulacre hauria de fer que la verificació tingui èxit.
// Arrange when(mockedIntList.get(anyInt())).thenReturn(3); // Act int response = mockedIntList.get(5); response = mockedIntList.get(2); // Assert verify(mockedIntList, atMost(2)).get(anyInt()); verify(mockedIntList, atMost(2)).size();
# 2) Coincidència d'arguments
En la invocació anterior, els combinadors es poden combinar juntament amb els argumentadors per validar els arguments amb els quals es va cridar la simulació.
- cap()
- Valors específics: verifiqueu amb els valors específics quan es coneixen prèviament els arguments.
- Altres coincidències d'arguments com: anyInt (), anyString (), etc.
Consells i trucs
# 1) Utilitzar Argument Capture durant la verificació
La verificació de la captura d’arguments sol ser útil quan l’argument utilitzat per algun mètode stubbed no es passa directament mitjançant una trucada de mètode, sinó que es crea internament quan es crida el mètode que es prova.
Això és essencialment útil quan el vostre mètode depèn d'un o més col·laboradors que hagin rebutjat el seu comportament. Els arguments transmesos a aquests col·laboradors són un objecte intern o un conjunt d'arguments completament nou.
Validar l’argument real amb què s’haurien cridat els col·laboradors garanteix molta confiança en el codi que s’està provant.
Mockito proporciona ArgumentCaptor que es pot utilitzar amb la verificació i, després, quan es crida “AgumentCaptor.getValue ()”, podem afirmar l’argument capturat real contra l’esperat.
Per il·lustrar-ho, consulteu l'exemple següent:
el millor convertidor de fitxers gratuït per a Windows 10
En el mètode següent, calculatePrice és el model amb la classe InventoryModel que es crea dins del cos del mètode que InventoryService utilitza per actualitzar.
Ara bé, si voleu escriure una prova per validar amb quin argument es va cridar l’inventariService, simplement podeu utilitzar l’objecte ArgumentCaptor de tipus classe InventoryModel.
Mètode sotmès a prova:
public double calculatePrice(int itemSkuCode) { double price = 0; // get Item details ItemSku sku = itemService.getItemDetails(itemSkuCode); // update item inventory InventoryModel model = new InventoryModel(); model.setItemSku(sku); model.setItemSuppliers(new String(){'Supplier1'}); inventoryService.updateInventory(model, 1); return sku.getPrice(); }
Codi de prova: Mireu el pas de verificació on es verifica l'inventariServei, es substitueix l'objecte argumentCaptor per l'argument que s'ha de fer coincidir.
A continuació, simplement afirmeu el valor invocant el mètode getValue () a l'objecte ArgumentCaptor.
Exemple: ArgumentCaptorObject.getValue ()
public void calculatePrice_withValidItemSku_returnsSuccess() { // Arrange ItemSku item1 = new ItemSku(); item1.setApplicableDiscount(5.00); item1.setPrice(100.00); CustomerProfile customerProfile = new CustomerProfile(); customerProfile.setExtraLoyaltyDiscountPercentage(2.00); double expectedPrice = 93.00; // Arrange when(mockedItemService.getItemDetails(anyInt())).thenReturn(item1); ArgumentCaptor argCaptorInventoryModel = ArgumentCaptor.forClass(InventoryModel.class); // Act priceCalculator.calculatePrice(1234); // Assert verify(mockedItemService).getItemDetails(anyInt()); verify(mockedInventoryService).updateInventory(argCaptorInventoryModel.capture(), eq(1)); assertEquals(argCaptorInventoryModel.getValue().itemSku, item1);
Sense ArgumentCaptor no hi hauria manera d’identificar amb quin argument es va fer la trucada de servei. El millor possible és utilitzar 'qualsevol ()' o 'qualsevol (InventoryModel.class)' per verificar arguments.
# 2) Excepcions / errors habituals en utilitzar Matchers
Mentre s’utilitzen Matchers, hi ha certes convencions que s’han de seguir, que si no se segueixen, generen una excepció. El més comú amb què em vaig trobar és el de restar i verificar.
Si utilitzeu qualsevol argumentMatchers i si el mètode stubbed té més d'un argument, llavors tots els arguments haurien de mencionar-se amb els coincidents, en cas contrari, cap d'ells no hauria de tenir coincidències. Ara, què significa això?
Intentem entendre-ho amb un escenari (i, a continuació, mostra de codi per a aquest escenari)
- Suposem que el mètode que es prova té una signatura com -
concatenateString (String arg1, String arg2) - Ara, quan elimineu - suposem que sabeu el valor d'arg1, però arg2 és desconegut, decidiu utilitzar un aparellador d'arguments com - any () o anyString () i especificar un valor per al primer argument, com ara un text 'hola'.
- Quan s'implementa el pas anterior i s'executa la prova, la prova genera una excepció anomenada 'InvalidUseOfMatchersException'
Intentem entendre-ho amb un exemple:
Codi de prova:
// Arrange when(a gMatcher.concatenateString('hello', anyString())).thenReturn('hello world!'); // Act String response = argMatcher.concatenateString('hello', 'abc'); // Assert verify(argMatcher).concatenateString(anyString(), anyString());
Classe a prova:
public class ArgMatcher { public String concatenateString(String arg1, String arg2) { return arg1.concat(arg2); } }
Quan s'executa la prova anterior, torna a ' InvalidUseOfMatchersException '
Ara bé, quin és el motiu d'aquesta excepció?
Es tracta de combinar amb aparelladors de peces i cadenes fixes, és a dir, hem esmentat un aparellador d’arguments com a “hola” i el segon com a anyString (). Ara hi ha dues maneres de desfer-se d'aquest tipus d'excepcions (també tingueu en compte que aquest comportament s'aplica tant a les configuracions de Mock com al comportament).
# 1) Utilitzeu els coincidents d’arguments per a tots els arguments:
// Arrange when(a gMatcher.concatenateString(anyString(), anyString())).thenReturn('hello world!'); // Act String response = argMatcher.concatenateString('hello', 'abc'); // Assert verify(argMatcher).concatenateString(anyString(), anyString());
# 2) Utilitzeu eq () com a Argument Matcher on es coneix l'argument. Per tant, en lloc d’especificar l’argument com a “hola”, especifiqueu-lo com a “eq” (“hola”) i això hauria de fer que l’acoblament tingués èxit.
// Arrange when(argMatcher.concatenateString(anyString(), eq('world'))).thenReturn('hello world!'); // Act String response = argMatcher.concatenateString('hello', 'world'); // Assert verify(argMatcher).concatenateString(anyString(), eq('world'));
Conclusió
En aquest article, hem vist com utilitzar diferents tipus de concordança proporcionats per Mockito.
Aquí, hem tractat els més utilitzats. Per referir-vos a la llista completa, la documentació de la Biblioteca de Mockito és una bona font de referència.
Consulteu el nostre proper tutorial per obtenir més informació sobre els mètodes de burla privats, estàtics i buits.
Lectura recomanada
- Creació de simulacres i espies a Mockito amb exemples de codi
- Tutorial de Mockito: Marc Mockito per burlar-se de les proves unitàries
- Tipus de riscos en projectes de programari
- Tipus de dades Python
- Tipus de dades C ++
- Top 12 de les preguntes sobre l'entrevista de Mockito (entrevista de Mocking Framework)
- Mofant de mètodes privats, estàtics i buits mitjançant Mockito
- Tipus d’herència en C ++