Menu

Výukový program Mockito: Rámec Mockito pro zesměšňování při testování jednotek


  • Hlavní
  • Jiný
  • Výukový program Mockito: Rámec Mockito pro zesměšňování při testování jednotek

mockito tutorial mockito framework

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Kompletní průvodce rámcem Mockito: Praktické návody Mockito


jak přidat prvek do pole v javě

Testování jednotek je jednoduchá, ale účinná technika k získání dobré úrovně důvěry v kód, který má být odeslán.

Navíc se vyhne problémům s regresí s každým kusem kódu, který se zkontroluje.


S architekturou typu mikroslužeb (a dokonce i pro jednoduchou strukturu zahrnující základní volání databáze) nestačí přímé testování jednotek. Potřebujeme zesměšňovat závislosti a otestovat skutečnou logiku testované metody.

Výukový průvodce pro Mockito


Seznam VŠECHNY návody Mockito v této sérii:

Výukový program č. 1: Mockito Framework pro zesměšňování při testování jednotek (Tento návod)
Výukový program č. 2: Vytváření Mocks and Spies in Mockito
Výukový program č. 3: Různé typy Matchers poskytované Mockito
Výukový program č. 4: Mocking soukromé, statické a neplatné metody pomocí Mockito
Výukový program č. 5: Top 12 Mockito Interview Questions

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


Přehled výukových programů v této sérii Mockito

Tutorial #Co se naučíte
Výukový program č. 1: Mockito Framework pro zesměšňování při testování jednotek

Naučte se zesměšňovat s Mockito - komplexní kurz Mockito pro začátečníky s příklady kódu. Naučte se Mocking Framework pro Mocking v testování jednotek.
Výukový program č. 2: Vytváření Mocks and Spies in Mockito

Mocks and Spies jsou typy testovacích dvojic, které jsou užitečné při psaní testů jednotek. Oba jsou vysvětleny v tomto kurzu Mockito Spy s příklady kódu.
Výukový program č. 3: Různé typy Matchers poskytované Mockito

Naučte se, jak používat různé typy porovnávačů poskytované společností Mockito. Odpovídající jsou jako zástupné znaky, kde místo konkrétního vstupu / výstupu určíte rozsah vstupu. Argument a ověření jsou dva typy Matcherů v Mockitu, které jsou podrobně vysvětleny zde.
Výukový program č. 4: Mocking soukromé, statické a neplatné metody pomocí Mockito

Naučte se zesměšňovat soukromé, statické a neplatné metody v Mockito s příklady. Naučte se zesměšňovat soukromé a statické metody pomocí testovacího rámce jednotek PowerMockito.
Výukový program č. 5: Top 12 Mockito Interview Questions

Mockito Interview Otázky a odpovědi s příklady ukázkových kódů. To vám pomůže úspěšně prolomit jakýkoli rozhovor s Mockito Mocking Framework.

Začněme prvním tutoriálem v této sérii !!

Co se naučíte:


Mocking in Unit testing

Mocks / Stubs je termín, který lidé běžně slyší při vytváření konkrétních testů jednotek.

Co tedy v podstatě je Mocking? Jednoduše řečeno, není to nic jiného než poskytnutí kontrolované instance nebo implementace závislosti, na které závisí testovaný kód, aby otestoval svou základní logiku.

Důvod, proč jsem to uvedl jako kontrolovanou instanci, je ten, že chování závislosti lze naprogramovat nebo řídit podle potřeby pro testovanou metodu nebo systém.

Abychom to vysvětlili schematicky, vezměme si příklad jakékoli obchodní nebo elektronické aplikace. Téměř každý takový typ aplikace má primárně 3 vrstvy, tj. Uživatelské rozhraní, obchodní vrstva a vrstva přístupu k datům (který mluví se základním úložištěm dat)

Příklad: UnitTesting Dependencies

S odkazem na výše uvedený diagram má Business Layer 3 závislosti, tj. Tj. Data Access Layer a 2 další služby, které jsou Service 1 a Service 2.

Podívejte se na to takto - Aplikace jako Google Maps mohou mít závislosti na

  1. Aktuální úložiště dat, jako je MySQL, nebo jakákoli jiná žádná databáze SQL, která ukládá data map.
  2. Externí služba jako CoordinateService, která poskytuje zeměpisné šířky a délky místa.
  3. Externí služba, jako je dopravní služba, která poskytuje dopravní informace v reálném čase pro daný pár souřadnic.

Takže pokud se někdo pokouší ověřit základní obchodní logiku pomocí testu jednotky, dokud a pokud nebude mít funkční implementace těchto závislostí, testy nelze spustit.

Mocks přijdou na záchranu v těchto situacích, kde bez ohledu na to, zda je vaše závislost spuštěna nebo ne, máte vždy zaručeno, že spustíte svou obchodní logiku s naprogramovanou odpovědí na závislost, která se volá z testovaného kódu.

Druhy / kategorie testovacích čtyřhry

Mock je v podstatě typ „Test Double“ - je to technický žargon. „Test Double“ v podstatě znamená objekt, který je nahrazen ekvivalentní instancí nebo závislostí skutečného objektu.

Níže jsou uvedeny různé typy testovacích dvojic:

# 1) Padělky:

Falešná je fungující implementace podobná skutečné závislosti, kromě skutečnosti, že je lokální pro testovaný systém.

Příklad: Namísto zasažení skutečné produkční databáze test používá k ukládání dat jednoduchou kolekci / paměť.

Typ zkušebního zdvojnásobení - padělky

# 2) Pahýly:

Útržky jsou předkonfigurované odpovědi, když je volána závislost z testovaného systému.

Typ zkušebního zdvojnásobení - pahýly

# 3) Špioni:

Jak název napovídá, je to vlastně volání skutečné funkce (závislosti) s nějakým sledovacím mechanismem. Odeslat hovor, lze ověřit, zda byl hovor skutečně spuštěn nebo ne spolu s parametry.

Typ zkušebního zdvojnásobení - špioni

# 4) Mocks:

Mocks jsou speciální instance objektů, na kterých lze zadat Stubbed / předkonfigurované odpovědi. Skutečnost, že falešný volal, lze ověřit jako tvrzení v testu.

Například:

Existuje funkce generátoru zpráv, která během provádění odesílá e-mail na zadanou adresu.

Protože nechceme posílat skutečné e-maily, znovu a znovu, během testování, je EmailService zesměšňována (a metoda e-mailu, která odesílá e-mail, je nakonfigurována tak, aby při volání nic nedělala). Na konci testu můžeme ověřit, že byla metoda posílání e-mailů e-mailové služby volána prostřednictvím zesměšňovaného objektu.

Různé falešné rámce

Téměř všechny jazyky poskytují různé druhy zesměšňujících rámců. Budeme psát ukázkový kód pomocí Mockito, což je open source Mocking framework pro Javu.

Anatomie jednoduchého jednotkového testu se zesměšňovanou závislostí. Předpokládejme, že se pokoušíme otestovat aplikaci, která vypočítá celkové známky pro studenta ze všech předmětů a zapíše ji do 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); }

Nyní, pokud chceme pro metodu napsat unit test - vypočítatSumAndStore, pak nemusíme mít skutečnou implementaci databáze pro uložení součtu. V takovém případě tuto funkci nikdy nebudeme moci testovat.

Ale s falešnými zprávami na místě můžeme jednoduše předat Mock pro databázovou službu a ověřit zbytek logiky

Ukázkový test, jak je znázorněno níže:

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

Viděli jsme ve výše uvedeném testu, že jsme poskytli objekt mockDatabase mateřské třídě (pro testovanou metodu) a nastavili jsme odpověď útržku pro objekt mockedDatabase - řádek # 6 výše (Mockito.doNothing (). When (mockDatabase) .updateScores („student1“, 220);)

Z výše uvedeného je třeba si uvědomit důležité body:

# 1) U zesměšňovaného objektu je třeba nastavit zarovnané odpovědi pro všechny metody, které budou volány během provádění funkce.

#dva) Parametry zadané při vytváření pahýlů mohou být konkrétní nebo obecné.

Příklad v předchozím případě - parametry metody updateScores jsme zadali jako „student1“ a 220, protože víme, že se jedná o přesné vstupy, kterými bude naše metoda volána.

# 3) Během ověřování ověřujeme následující:

  • Byla volána metoda mockDatabase.updateScores.
  • Argumenty byly „student1“ a 220.
  • Metoda updateScores byla volána 1krát.

Zkusme nyní trochu změnit tento testovací kód a uvidíme, co se stane:

Změním argument ve falešném nastavení z „student1“ na anyString (Mockito poskytuje standardní matcher s názvem anyString ()) a 220 na anyInteger (Mockito poskytuje standardní matcher s názvem anyInt () a odpovídá jakékoli celočíselné hodnotě)

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

Zkuste test spustit znovu a test by měl být stále zelený.

(Nyní zkusme změnit ověření / tvrzení a změnit kterýkoli z argumentů.

Pojďme změnit 220 na 230. Nyní se očekává, že test by měl selhat, protože to není očekávaný argument, s nímž musí být volána databázeUpdate.

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

Po spuštění testu si přečtěte protokoly chyb, jak je uvedeno níže (jasně uvádí, že skutečné argumenty neodpovídají očekávaným).

Argumenty se liší! Chtěli:
mockDatabase.updateScores („student1“, 230);
-> na com.mocking.sampleMocks.StudentScoreUpdatesUnitTests.calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb (StudentScoreUpdatesUnitTests.java:37)

Skutečné vyvolání má různé argumenty:
mockDatabase.updateScores („student1“, 220);

Zdrojový kód

Rozhraní - IDatabase.java

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

Třída pod testem - 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); } }

Třída testů jednotek - 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); } }

Závěr

To, co jsme zatím viděli, je velmi základní a přímý příklad nastavení Mock pomocí rámce Java Mockito.

U téměř 60–70% jednotkových testů zahrnujících falešné testy by testy měly mít podobnou strukturu. Mockito poskytuje mnoho pokročilé konfigurace / podpory pro rozsáhlé posměšné potřeby, vkládá falešné instance pomocí injekce závislostí, poskytuje Spiesovi, aby skutečně špehoval volání skutečné metody a ověřil volání.

Náš nadcházející výukový program vysvětlí více o konceptu Mocks and Spies in Mockito.

DALŠÍ výuka

Doporučené čtení


^