mockito tutorial mockito framework
Una guia completa de Mockito Framework: tutorials pràctics de Mockito
quina és la clau de seguretat de la xarxa en un encaminador
La prova d’unitat és una tècnica senzilla però eficaç per obtenir un bon nivell de confiança en el codi que s’ha d’enviar.
A més, evita problemes de regressió amb cada tros de codi que es registra.
Amb un tipus d’arquitectura de microserveis (i fins i tot per a estructures senzilles que impliquen trucades bàsiques a bases de dades), les proves d’unitats senzilles no són suficients. El que necessitem és burlar-nos de les dependències i provar la lògica real del mètode que es prova.
Llista de TOTS els tutorials de Mockito d'aquesta sèrie:
Tutorial # 1: Marc Mockito per burlar-se de les proves unitàries (Aquest tutorial)
Tutorial # 2: Creació de simulacres i espies a Mockito
Tutorial # 3: Diferents tipus de coincidents proporcionats per Mockito
Tutorial # 4: Mofant de mètodes privats, estàtics i buits mitjançant Mockito
Tutorial # 5: Top 12 de les preguntes de l'entrevista de Mockito
************************************************** ********************
Visió general dels tutorials d'aquesta sèrie Mockito
| tutorial # | Què aprendràs |
|---|---|
| Tutorial # 1: | Marc Mockito per burlar-se de les proves unitàries Apreneu a burlar-vos de Mockito: un complet tutorial de Mockito per a principiants amb exemples de codi. Apreneu el marc burlador per burlar-se de les proves unitàries. |
| Tutorial # 2: | Creació de simulacres i espies a Mockito Els simulacres i els espies són tipus de dobles de proves, que són útils per escriure proves unitàries. Tots dos s’expliquen en aquest tutorial de Mockito Spy amb exemples de codi. |
| Tutorial # 3: | Diferents tipus de coincidents proporcionats per Mockito Apreneu a utilitzar els diferents tipus de concordança proporcionats per Mockito. Els coincidents són com a comodins on en lloc d’una entrada / sortida específica especifiqueu un interval d’entrada. L’argument i la verificació són els dos tipus de coincidències de Mockito que s’expliquen detalladament aquí. |
| Tutorial # 4: | Mofant de mètodes privats, estàtics i buits mitjançant Mockito Apreneu mètodes de burla privada, estàtica i buida a Mockito amb exemples. Apreneu a burlar-vos de mètodes privats i estàtics mitjançant el marc de proves d’unitats PowerMockito. |
| Tutorial # 5: | Top 12 de les preguntes de l'entrevista de Mockito Preguntes i respostes de l'entrevista Mockito amb exemples de codi de mostra. Això us ajudarà a trencar amb èxit qualsevol entrevista de Mockito Mocking Framework. |
Comencem pel primer tutorial d'aquesta sèrie !!
Què aprendreu:
- Mofes a les proves d’unitats
- Tipus / categories de dobles de prova
- Diferents marcs burlats
- Codi font
- Conclusió
- Lectura recomanada
Mofes a les proves d’unitats
Mocks / Stubs és un terme que la gent sol escoltar en crear proves unitàries en particular.
Llavors, què és essencialment Mocking? En termes simples, no és res més que proporcionar una instància controlada o una implementació de dependència de què depengui el codi que es prova per tal de provar la seva lògica principal.
El motiu pel qual l’he esmentat com una instància controlada és que el comportament de la dependència es pot programar o controlar com es desitgi per al mètode o sistema que es prova.
Per explicar-ho esquemàticament, posem un exemple de qualsevol aplicació comercial o de comerç electrònic. Gairebé tots aquests tipus d'aplicacions tenen principalment 3 capes, és a dir, Interfície d'usuari, capa de negoci i capa d'accés a dades (que parla amb el magatzem de dades subjacent)
En referència al diagrama anterior, Business Layer té 3 dependències, és a dir, Data Access Layer i 2 altres serveis que són el Servei 1 i el Servei 2.
Mireu-ho d'aquesta manera: una aplicació com Google Maps pot tenir dependències en un
- Magatzems de dades reals com MySQL o qualsevol altra base de dades sense SQL que emmagatzemi dades de mapes.
- Un servei extern com CoordinateService que proporciona latituds i longituds d’una ubicació.
- Un servei extern com el servei de trànsit que proporciona informació de trànsit en temps real per a un parell de coordenades determinat.
Per tant, si algú intenta validar la lògica principal del negoci mitjançant la prova unitària, fins que i tret que tinguin implementacions funcionals d’aquestes dependències, les proves no es podrien executar.
Els simulacres vénen a rescat en aquestes situacions, independentment de si la vostra dependència està en funcionament o no, sempre teniu la garantia d’executar la vostra lògica empresarial amb una resposta programada per a la dependència que s’està cridant des del codi que es prova.
Tipus / categories de dobles de prova
El simulacre és essencialment un tipus de 'prova doble': és un argot tecnològic. 'Prova doble' significa essencialment un objecte que se substitueix per una instància o dependència d'objecte real equivalent.
Hi ha diferents tipus de dobles de prova, tal com s’esmenta a continuació:
# 1) Falses:
Una falsificació és una implementació de treball similar a una dependència real, excepte el fet que és local al sistema que es prova.
Exemple: En lloc d’accedir a una base de dades de producció real, la prova utilitza una col·lecció / memòria senzilla per emmagatzemar dades.
# 2) Talons:
Els talons són respostes preconfigurades quan es crida una dependència des del sistema que es prova.
# 3) Espies:
Com el seu nom indica, en realitat és la funció real (dependència) anomenada amb algun mecanisme de vigilància. Envia la trucada, es pot verificar si la trucada s'ha activat o no juntament amb els paràmetres.
# 4) Mofes:
Els simulacres són instàncies especials d’objectes sobre els quals es poden especificar respostes discontínues o preconfigurades. El fet que es cridi al simulador es pot verificar com a afirmació a la prova.
Per exemple:
Hi ha una funció de generador d'informes que envia un correu electrònic a una adreça especificada durant l'execució.
Com que no volem enviar correus electrònics reals, una vegada i una altra, durant les proves, el servei de correu electrònic es burla (i el mètode de correu electrònic que envia el correu electrònic està configurat per no fer res quan es crida). Al final de la prova, només podem verificar que el mètode d'enviament de correu electrònic del servei de correu electrònic s'hagi cridat a través de l'objecte burlat.
Diferents marcs burlats
Gairebé tots els idiomes proporcionen diferents tipus de marcs de burla. Escriureem un codi de mostra amb Mockito, que és un framework de codi obert per a Java.
Anatomia d'un test unitari senzill amb dependència burlada. Suposem que estem intentant provar per unitat una aplicació que calcula les notes totals d’un estudiant en totes les assignatures i l’escriu a DB.
public void calculateSumAndStore(String studentId, int() scores) { int total = 0; for (int score: scores) { total = total + score; } // write total to DB databaseImpl.updateScores(studentId, total); } Ara bé, si volem escriure una prova unitària per al mètode: calculateSumAndStore, és possible que no tinguem una implementació real d’una base de dades per emmagatzemar el total. En aquest cas, mai no podrem provar aquesta funció per unitats.
Però amb els simulacres al seu lloc, simplement podem passar un Mock per al servei de base de dades i validar la resta de la lògica
Prova de mostra com es mostra a continuació:
@Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = { 60, 70, 90 }; Mockito.doNothing().when(mockDatabase).updateScores('student1', 220); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 220); } Vam veure a la prova anterior, hem proporcionat un objecte mockDatabase a la classe pare (per al mètode que es prova) i hem configurat una resposta de tall per a l’objecte mockedDatabase - Línia núm. 6 anterior (Mockito.doNothing (). When (mockDatabase) .updateScores ('student1', 220);)
Els punts importants que cal destacar de l’anterior són:
# 1) L'objecte burlat ha de configurar respostes contundents per a tots els mètodes que es cridaran durant l'execució de la funció.
# 2) Els paràmetres especificats durant la creació de memòries poden ser específics o genèrics.
Exemple en el cas anterior, hem especificat els paràmetres per al mètode updateScores com a 'estudiant1' i 220 perquè sabem que aquestes són les entrades exactes amb les que es dirà el nostre mètode.
# 3) Durant la verificació, estem validant el següent:
- Es va cridar el mètode mockDatabase.updateScores.
- Els arguments eren 'student1' i 220 respectivament.
- El mètode updateScores es va anomenar 1 vegada.
Ara provem de canviar una mica aquest codi de prova i vegem què passa:
Canviaré l'argument de la configuració simulada de 'student1' a anyString (Mockito proporciona un aparellador estàndard anomenat anyString ()) i 220 a qualsevol enter (Mockito proporciona un aparellador estàndard anomenat anyInt () i coincideix amb qualsevol valor enter)
@Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = { 60, 70, 90 }; Mockito.doNothing().when(mockDatabase).updateScores(anyString(), anyInt()); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 220); } Torneu a provar d'executar la prova i la prova encara hauria de ser verda.
(Ara, provem de canviar la verificació / afirmacions i canviar qualsevol dels arguments.
Canviem de 220 a 230. Ara l’expectativa és que la prova falli, ja que no és l’argument esperat amb què s’ha d’haver cridat a databaseUpdate.
@Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = { 60, 70, 90 }; Mockito.doNothing().when(mockDatabase).updateScores(anyString(), anyInt()); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 230); } Després d'executar la prova, consulteu els registres d'errors com es mostra a continuació (esmenta clarament que els arguments reals no coincideixen amb els esperats).
Els arguments són diferents. Volia:
mockDatabase.updateScores ('estudiant1', 230);
-> a com.mocking.sampleMocks.StudentScoreUpdatesUnitTests.calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb (StudentScoreUpdatesUnitTests.java:37)
La invocació real té diferents arguments:
mockDatabase.updateScores ('estudiant1', 220);
Codi font
Interfície: IDatabase.java
public interface IDatabase { public void updateScores(String studentId, int total); }Class Under Test - StudentScoreUpdates.java
public class StudentScoreUpdates { public IDatabase databaseImpl; public StudentScoreUpdates(IDatabase databaseImpl) { this.databaseImpl = databaseImpl; } public void calculateSumAndStore(String studentId, int() scores) { int total = 0; for(int score : scores) { total = total + score; } // write total to DB databaseImpl.updateScores(studentId, total); } } Classe de proves d’unitat - StudentScoreUpdatesUnitTests.java
public class StudentScoreUpdatesUnitTests { @Mock public IDatabase mockDatabase; public StudentScoreUpdates studentScores; @BeforeEach public void beforeEach() { MockitoAnnotations.initMocks(this); } @Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = {60,70,90}; Mockito.doNothing().when(mockDatabase).updateScores(anyString(), anyInt()); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 230); } } Conclusió
El que hem vist fins ara és un exemple molt bàsic i senzill d’instal·lació de Mock mitjançant el framework Mockito de Java.
Durant gairebé el 60-70% de les proves unitàries que impliquen simulacions, les proves haurien de tenir una estructura similar. Mockito proporciona una gran quantitat de configuració avançada / suport per a necessitats de burla extenses, injectant instàncies simulades mitjançant injecció de dependència, proporciona Spies per espiar una trucada de mètode real i verificar-les.
El nostre proper tutorial explicarà més sobre el concepte de burles i espies a Mockito.
Lectura recomanada
- Top 12 de les preguntes sobre l'entrevista de Mockito (entrevista de Mocking Framework)
- Tutorials Eclipse en profunditat per a principiants
- Com es configura el marc de proves Node.js: tutorial de Node.js
- Proves d’unitat d’escriptura amb Spock Framework
- Les diferències entre la prova unitària, la prova d’integració i la prova funcional
- Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
- Tutorial de proves destructives i proves no destructives
- Proves funcionals contra proves no funcionals