Menü

Mockito Eğitimi: Birim Testinde Alay için Mockito Çerçevesi

  • Ana
  • Diğer
  • Mockito Eğitimi: Birim Testinde Alay için Mockito Çerçevesi

mockito tutorial mockito framework

Sorunları Ortadan Kaldırmak Için Enstrümanımızı Deneyin

Mockito Framework için Tam Bir Kılavuz: Uygulamalı Mockito Eğitimleri

en iyi vr uygulaması nedir

Birim testi, sevk edilecek kodda iyi bir güven düzeyi elde etmek için basit ama etkili bir tekniktir.

Dahası, iade edilen her kod parçasıyla ilgili regresyon sorunlarını önler.

Mikro hizmet türü mimari ile (ve hatta temel veritabanı çağrılarını içeren basit yapı için), basit birim testi yeterli değildir. İhtiyacımız olan şey, bağımlılıklarla dalga geçmek ve test edilen yöntemin gerçek mantığını test etmektir.

Mockito eğitim kılavuzu

Bu Serideki TÜM Mockito Öğreticilerinin Listesi:

Öğretici 1: Birim Testinde Alay için Mockito Çerçeve (Bu Eğitim)
Öğretici # 2: Mockito'da Taklitler ve Casuslar Oluşturma
Öğretici 3: Mockito Tarafından Sağlanan Farklı Eşleştirici Türleri
Eğitim 4: Mockito Kullanarak Özel, Statik ve Geçersiz Yöntemleri Alay Etmek
Öğretici 5: En İyi 12 Mockito Röportaj Sorusu

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

Bu Mockito Serisindeki Öğreticilere Genel Bakış

Eğitici #Ne öğreneceksin
Öğretici 1: Birim Testinde Alay için Mockito Çerçeve

Mockito ile alay etmeyi öğrenin - Kod örnekleriyle yeni başlayanlar için kapsamlı bir Mockito Eğitimi. Unit Testing'de Mocking için Mocking Framework öğrenin.
Öğretici # 2: Mockito'da Taklitler ve Casuslar Oluşturma

Sahte ve Casuslar, birim testleri yazmada yardımcı olan test çiftleri türleridir. Her ikisi de bu Mockito Spy eğitiminde kod örnekleriyle açıklanmıştır.
Öğretici 3: Mockito Tarafından Sağlanan Farklı Eşleştirici Türleri

Mockito tarafından sağlanan farklı eşleştiricilerin nasıl kullanılacağını öğrenin. Eşleştiriciler, belirli bir girdi / çıktı yerine bir girdi aralığı belirttiğiniz joker karakterler gibidir. Argüman ve Doğrulama, Mockito'daki iki tür Eşleştiricidir ve burada ayrıntılı olarak açıklanmıştır.
Eğitim 4: Mockito Kullanarak Özel, Statik ve Geçersiz Yöntemleri Alay Etmek

Örneklerle Mockito'da Mocking Private, Static ve Void yöntemlerini öğrenin. PowerMockito birim testi çerçevesi ile özel ve statik yöntemleri alay etmeyi öğrenin.
Öğretici 5: En İyi 12 Mockito Röportaj Sorusu

Mockito Röportaj Soruları ve örnek kod örnekleriyle yanıtları. Bu, herhangi bir Mockito Mocking Framework röportajını başarıyla kırmanıza yardımcı olacaktır.

Bu serideki ilk eğiticiyle başlayalım !!

Ne öğreneceksin:

Birim testinde alay

Mocks / Stubs, özellikle birim testleri oluştururken insanların sıklıkla duyduğu bir terimdir.

Öyleyse, alay konusu nedir? Basit bir ifadeyle, test edilen kodun temel mantığını test etmek için bağlı olduğu kontrollü bir örnek veya bağımlılık uygulaması sağlamaktan başka bir şey değildir.

Kontrollü bir örnek olarak bahsetmemin nedeni, bağımlılığın davranışının test edilen yöntem veya sistem için istenildiği gibi programlanabilmesi veya kontrol edilebilmesidir.

Bunu şematik olarak açıklamak için, herhangi bir İşletme veya E-ticaret Uygulaması örneğini ele alalım. Hemen hemen her tür uygulama türü öncelikle 3 katmana sahiptir, yani Kullanıcı Arayüzü, İş Katmanı ve Veri Erişim katmanı (temeldeki veri deposuyla konuşur)

Örnek: UnitTesting Dependencies

Yukarıdaki diyagrama bakıldığında, İş Katmanının 3 bağımlılığı vardır, yani Veri Erişim Katmanı ve Hizmet 1 ve Hizmet 2 olan diğer 2 hizmet.

Buna şu şekilde bakın - Google haritaları gibi bir uygulamanın bir

  1. Gerçek veriler MySQL veya Harita verilerini depolayan diğer SQL veritabanı gibi depolar.
  2. CoordinateService gibi bir konumun enlem ve boylamlarını sağlayan harici bir hizmet.
  3. Belirli bir Koordinat çifti için gerçek zamanlı trafik bilgisi sağlayan trafik hizmeti gibi harici bir hizmet.

Bu nedenle, birisi birim testi kullanarak temel iş mantığını doğrulamaya çalışıyorsa, bu bağımlılıkların çalışan uygulamalarına sahip olana kadar ve olmadıkça, testler çalıştırılamaz.

Bağımlılığınızın çalışıp çalışmadığına bakılmaksızın, test edilen koddan çağrılan bağımlılık için programlanmış bir yanıtla iş mantığınızı çalıştırmanız her zaman garanti edilir.

Çift Test Türleri / Kategorileri

Mock, aslında bir tür 'İkili Test Et' - bir teknoloji jargonu. 'Test Double' esasen eşdeğer gerçek nesne durumu veya bağımlılığı ile değiştirilen bir nesne anlamına gelir.

Aşağıda belirtildiği gibi farklı Test çiftleri türleri vardır:

# 1) Sahte:

Sahte, test edilen sisteme yerel olması dışında gerçek bir bağımlılığa benzer çalışan bir uygulamadır.

Misal: Test, gerçek bir üretim DB'sine ulaşmak yerine, verileri depolamak için basit bir koleksiyon / bellek içi kullanır.

Çift Test Türü - Sahte

# 2) Taslaklar:

Stub'lar, test edilen sistemden bir bağımlılık çağrıldığında önceden yapılandırılmış yanıtlardır.

Test Tipi Çiftler - Stub

# 3) Casuslar:

Adından da anlaşılacağı gibi, aslında gerçek işlevi (bağımlılık) bazı izleme mekanizmalarıyla çağırır. Çağrıyı gönderin, çağrının gerçekten tetiklenip tetiklenmediği parametrelerle birlikte doğrulanabilir.

Test Türü Çiftler - Casuslar

# 4) Taklitler:

Taklitler, üzerinde Stubbed / önceden yapılandırılmış yanıtların belirtilebileceği nesnelerin özel örnekleridir. Taklidin çağrılması, testte bir iddia olarak doğrulanabilir.

Örneğin:

Yürütme sırasında belirli bir adrese e-posta gönderen bir rapor oluşturma işlevi vardır.

Test sırasında tekrar tekrar gerçek e-posta göndermek istemediğimizden, E-posta Hizmeti ile alay edilir (ve e-postayı gönderen e-posta yöntemi, çağrıldığında hiçbir şey yapmayacak şekilde yapılandırılır). Testin sonunda, e-posta hizmetinin e-posta gönderme yönteminin sahte nesne aracılığıyla çağrıldığını doğrulayabiliriz.

Farklı Alay Çerçeveleri

Hemen hemen tüm diller farklı türde alay etme çerçeveleri sağlar. Java için açık kaynaklı bir Mocking çerçevesi olan Mockito kullanarak örnek bir kod yazacağız.

Bağımlılıkla alay edilen basit bir birim testinin anatomisi. Diyelim ki, bir öğrencinin tüm konulardaki toplam puanlarını hesaplayan ve bunu DB'ye yazan bir uygulamayı birim test etmeye çalışıyoruz.

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

Şimdi, yöntem için bir birim testi yazmak istiyorsak - calculateSumAndStore, toplamı depolamak için gerçek bir veritabanı uygulamasına sahip olmayabiliriz. Bu durumda, bu işlevi hiçbir zaman birim test edemeyeceğiz.

Ancak taklitler uygulandığında, veritabanı hizmeti için bir Mock geçirebilir ve mantığın geri kalanını doğrulayabiliriz.

Aşağıda gösterildiği gibi örnek test:

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

Yukarıdaki testte gördük, üst sınıfa bir mockDatabase nesnesi sağladık (test edilen yöntem için) ve mockedDatabase nesnesi için bir saplama yanıtı oluşturduk - yukarıdaki Satır # 6 (Mockito.doNothing (). When (mockDatabase) .updateScores ('öğrenci1', 220);)

Yukarıdakilere dikkat edilmesi gereken önemli noktalar şunlardır:

# 1) Alay konusu nesnenin, işlevin yürütülmesi sırasında çağrılacak tüm yöntemler için stublanmış yanıtlar kurması gerekir.

#iki) Saplama oluşturma sırasında belirtilen parametreler özel veya genel olabilir.

Misal Yukarıdaki durumda - updateScores yöntemi için parametreleri 'öğrenci1' ve 220 olarak belirledik çünkü bunların, yöntemimizin çağrılacağı kesin girdiler olduğunu biliyoruz.

# 3) Doğrulama sırasında aşağıdakileri doğrularız:

  • mockDatabase.updateScores yöntemi çağrıldı.
  • Argümanlar sırasıyla 'öğrenci1' & 220 idi.
  • UpdateScores yöntemi 1 kez çağrıldı.

Şimdi bu test kodunu biraz değiştirmeyi deneyelim ve ne olacağını görelim:

Sahte kurulumdaki argümanı 'öğrenci1' den anyString'e değiştireceğim (Mockito, anyString () adlı standart bir eşleştirici sağlar) ve 220'den anyInteger'a (Mockito, anyInt () adlı standart bir eşleştirici sağlar ve herhangi bir tam sayı değeriyle eşleşir)

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

Testi tekrar çalıştırmayı deneyin ve test hala yeşil renkte olmalıdır.

(Şimdi, doğrulamayı / iddiaları değiştirmeyi ve argümanlardan herhangi birini değiştirmeyi deneyelim.

220'yi 230'a değiştirelim. Şimdi, bu, databaseUpdate'in çağrılması gereken beklenen argüman olmadığından, testin başarısız olması beklenir.

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

Testi çalıştırdıktan sonra, aşağıda gösterildiği gibi hata günlüklerine başvurun (gerçek bağımsız değişkenlerin beklenenlerle eşleşmediğini açıkça belirtir).

Bağımsız değişken (ler) farklı! Aranan:
mockDatabase.updateScores ('öğrenci1', 230);
-> com.mocking.sampleMocks.StudentScoreUpdatesUnitTests.calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb (StudentScoreUpdatesUnitTests.java:37) adresinde

Gerçek çağrının farklı argümanları vardır:
mockDatabase.updateScores ('öğrenci1', 220);

Kaynak kodu

Arayüz - IDatabase.java

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

Test Edilen Sınıf - 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); } }

Birim Testleri Sınıfı - 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); } }

Sonuç

Şimdiye kadar gördüklerimiz, Java'nın Mockito çerçevesini kullanan çok basit ve anlaşılır bir Mock kurulum örneğidir.

Taklitleri içeren birim testlerin neredeyse% 60-70'i için testlerin benzer bir yapıya sahip olması gerekir. Mockito, bağımlılık enjeksiyonu kullanarak sahte örnekleri enjekte ederek kapsamlı alay ihtiyaçları için çok sayıda gelişmiş yapılandırma / destek sağlar, Casusların gerçek bir yöntem çağrısını gerçekten gözetlemesini ve çağrıları doğrulamasını sağlar.

Yaklaşan eğitimimiz Mockito'daki Mocks ve Casus Kavramı hakkında daha fazla bilgi verecektir.

SONRAKİ Eğitici

Önerilen Kaynaklar

^