Meniu

Tutorial Mockito: Mockito Framework pentru batjocură în testarea unității

  • Principal
  • Alte
  • Tutorial Mockito: Mockito Framework pentru batjocură în testarea unității

mockito tutorial mockito framework

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Un ghid complet pentru Mockito Framework: Tutoriale practice Mockito

aplicații pentru a converti videoclipuri YouTube în mp3

Testarea unității este o tehnică simplă, dar eficientă, pentru a câștiga un nivel bun de încredere în codul care urmează să fie livrat.

Mai mult, evită problemele de regresie cu fiecare fragment de cod care este înregistrat.

Cu tipul de arhitectură de tip micro-servicii (și chiar și pentru structura simplă care implică apeluri de bază de date), testarea unitară simplă nu este suficientă. Ceea ce avem nevoie este să batem joc de dependențe și să testăm logica reală a metodei testate.

Ghid tutorial Mockito

Lista TUTURELOR Tutoriale Mockito din această serie:

Tutorial nr. 1: Cadrul Mockito pentru batjocura în testarea unității (Acest tutorial)
Tutorial nr. 2: Crearea de batjocuri și spioni în Mockito
Tutorial # 3: Diferite tipuri de chibrituri furnizate de Mockito
Tutorial # 4: Batjocorind metode private, statice și vid folosind Mockito
Tutorial # 5: Top 12 întrebări de interviu Mockito

************************************************** * *******************

Prezentare generală a tutorialelor din această serie Mockito

Tutorial #Ce vei învăța
Tutorial nr. 1: Cadrul Mockito pentru batjocura în testarea unității

Aflați batjocura cu Mockito - Un tutorial cuprinzător Mockito pentru începători cu exemple de cod. Aflați cadrul de batjocură pentru batjocură în testarea unitară.
Tutorial nr. 2: Crearea de batjocuri și spioni în Mockito

Mock-urile și spionii sunt tipuri de teste duble, care sunt utile în scrierea testelor unitare. Ambele sunt explicate în acest tutorial Mockito Spy cu exemple de cod.
Tutorial # 3: Diferite tipuri de chibrituri furnizate de Mockito

Aflați cum să utilizați diferite tipuri de chibrituri furnizate de Mockito. Matchers sunt ca niște metacaractere în care, în loc de o intrare / ieșire specifică, specificați o gamă de intrare. Argumentul și verificarea sunt cele două tipuri de meciuri din Mockito care sunt explicate în detaliu aici.
Tutorial # 4: Batjocorind metode private, statice și vid folosind Mockito

Aflați metodele private de batjocură, statice și vid în Mockito cu exemple. Aflați metode private și statice batjocoritoare prin cadrul de testare a unității PowerMockito.
Tutorial # 5: Top 12 întrebări de interviu Mockito

Mockito Interviu Întrebări și răspunsuri cu exemple de coduri. Acest lucru vă va ajuta să spargeți cu succes orice interviu Mockito Mocking Framework.

Să începem cu primul tutorial din această serie !!

Ce veți învăța:

Batjocură în testarea unității

Mocks / Stubs este un termen pe care oamenii îl aud în mod obișnuit în timp ce creează teste unitare în special.

Deci, ce este în esență Mocking? În termeni simpli, nu este altceva decât să ofere o instanță controlată sau o implementare a dependenței de care depinde codul testat pentru a-și testa logica de bază.

Motivul pentru care l-am menționat ca instanță controlată este că comportamentul dependenței poate fi programat sau controlat după cum se dorește pentru metoda sau sistemul testat.

Pentru a o explica schematic, să luăm un exemplu al oricărei aplicații comerciale sau de comerț electronic. Aproape fiecare astfel de tip de aplicație are în principal 3 straturi, adică Interfață utilizator, strat business și strat de acces la date (care vorbește cu magazinul de date subiacent)

Exemplu: Dependențe UnitTesting

Referindu-ne la diagrama de mai sus, Business Layer are 3 dependențe și anume Data Access Layer și alte 2 servicii care sunt Serviciul 1 și Serviciul 2.

Uitați-vă în acest fel - o aplicație precum Google Maps poate avea dependențe de un

  1. Stocuri de date reale precum MySQL sau orice altă bază de date fără SQL care stochează date de hartă.
  2. Un serviciu extern precum CoordinateService care oferă latitudini și longitudini ale unei locații.
  3. Un serviciu extern, cum ar fi serviciul de trafic, care oferă informații despre trafic în timp real pentru o anumită pereche de coordonate.

Deci, dacă cineva încearcă să valideze logica de bază a afacerii folosind testul de unitate, până și dacă nu are implementări funcționale ale acestor dependențe, testele nu au putut fi executate.

Mock-urile vin să se salveze în aceste situații, în care indiferent că dependența dvs. este activă sau nu, aveți întotdeauna garanția de a vă rula logica de afaceri cu un răspuns programat pentru dependența care este apelată din codul testat.

Tipuri / Categorii de teste duble

Mock este în esență un tip de „test dublu” - este un jargon tehnologic. „Test dublu” înseamnă în esență un obiect care este înlocuit cu o instanță sau dependență echivalentă de obiect real.

Există diferite tipuri de teste duble, după cum se menționează mai jos:

# 1) Falsuri:

Un fals este o implementare funcțională similară cu o dependență reală, cu excepția faptului că este locală pentru sistemul testat.

Exemplu: În loc să lovească un DB de producție real, testul folosește o colecție simplă / în memorie pentru a stoca date.

Tipul de test dublu - Falsuri

# 2) Butoane:

Stuburile sunt răspunsuri preconfigurate atunci când se apelează o dependență din sistemul testat.

Tipul testelor duble - Butoane

# 3) Spioni:

După cum sugerează și numele, este de fapt apelul funcției reale (dependență) cu un mecanism de urmărire. Postați apelul, se poate verifica dacă apelul a fost efectiv declanșat sau nu împreună cu parametrii.

Tipul de test dublu - Spioni

# 4) Batjocuri:

Mock-urile sunt instanțe speciale de obiecte, pe care pot fi specificate răspunsuri Stubbed / pre-configurate. Faptul că simulatorul a fost sunat poate fi verificat ca o afirmare în test.

De exemplu:

Există o funcție generatoare de rapoarte care trimite un e-mail la o adresă specificată în timpul execuției.

Întrucât nu dorim să trimitem e-mailuri reale, din nou și din nou, în timpul testării, serviciul de e-mail este batjocorit (iar metoda de e-mail care trimite e-mailul este configurată să nu facă nimic atunci când este apelată). La sfârșitul testului, putem verifica doar dacă metoda de trimitere a e-mail a serviciului de e-mail a fost apelată prin obiectul batjocorit.

Diferite cadre de batjocură

Aproape toate limbile oferă diferite tipuri de cadre de batjocură. Vom scrie un exemplu de cod folosind Mockito, care este un cadru de sursă open source pentru Java.

Anatomia unui test unitar simplu cu dependență batjocorită. Să presupunem că încercăm să testăm în unitate o aplicație care calculează notele totale pentru un student la toate subiectele și o scrie pe 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); }

Acum, dacă vrem să scriem un test unitar pentru metoda - calculateSumAndStore, atunci s-ar putea să nu avem o implementare reală a unei baze de date pentru a stoca totalul. În acest caz, nu vom putea testa niciodată această funcție.

Însă, cu jocuri în loc, putem pur și simplu să trecem un Mock pentru serviciul de baze de date și să validăm restul logicii

Test de probă așa cum se arată mai jos:

@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); }

Am văzut în testul de mai sus, am furnizat un obiect mockDatabase clasei părinte (pentru metoda testată) și am configurat un răspuns stub pentru obiectul mockedDatabase - Linia # 6 de mai sus (Mockito.doNothing (). When (mockDatabase) .updateScores („student1”, 220);)

Punctele importante de menționat din cele de mai sus sunt:

# 1) Obiectul batjocorit trebuie să configureze răspunsuri stub pentru toate metodele care vor fi apelate în timpul executării funcției.

#Două) Parametrii specificați în timpul creării stub pot fi specifici sau generici.

Exemplu în cazul de mai sus - am specificat parametrii pentru metoda updateScores ca „student1” și 220 deoarece știm că acestea sunt intrările exacte cu care va fi apelată metoda noastră.

# 3) În timpul verificării, validăm următoarele:

  • s-a apelat metoda mockDatabase.updateScores.
  • Argumentele au fost „student1” și respectiv 220.
  • Metoda updateScores a fost numită o dată.

Acum, încercăm să schimbăm puțin acest cod de test și să vedem ce se întâmplă:

Voi schimba argumentul din configurația simulată de la „student1” la anyString (Mockito oferă un potrivitor standard numit anyString ()) și 220 la anyInteger (Mockito oferă un potrivitor standard numit anyInt () și se potrivește cu orice valoare întreagă)

@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); }

Încercați din nou să rulați testul și testul ar trebui să fie în continuare verde.

(Acum să încercăm să schimbăm verificarea / afirmațiile și să schimbăm oricare dintre argumente.

Să schimbăm 220 la 230. Acum se așteaptă ca testul să eșueze, deoarece acesta nu este argumentul așteptat cu care trebuie să fi fost apelat 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); }

După rularea testului, consultați jurnalele de erori așa cum se arată mai jos (menționează clar că argumentele efective nu se potriveau cu cele așteptate).

Argumentele sunt diferite! Dorit:
mockDatabase.updateScores („student1”, 230);
-> la com.mocking.sampleMocks.StudentScoreUpdatesUnitTests.calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb (StudentScoreUpdatesUnitTests.java:37)

Invocarea efectivă are argumente diferite:
mockDatabase.updateScores („student1”, 220);

Cod sursa

Interfață - IDatabase.java

public interface IDatabase { public void updateScores(String studentId, int total); }

Clasa sub 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); } }

Clasa de teste unitare - 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); } }

Concluzie

Ceea ce am văzut până acum este un exemplu foarte simplu și simplu de configurare Mock utilizând cadrul Java Mockito.

Pentru aproape 60-70% din testele unitare care implică simulări, testele ar trebui să aibă o structură similară. Mockito oferă o mulțime de configurații / suport avansate pentru nevoi de batjocură extinse, injectând instanțe simulate folosind injecția de dependență, oferă spionilor să spioneze efectiv un apel cu metodă reală și să verifice apelurile.

Următorul nostru tutorial va explica mai multe despre Conceptul de batjocuri și spioni din Mockito.

NEXT Tutorial

Lectură recomandată

^