Menü

En İyi 12 Sahte Görüşme Sorusu (Alaycı Çerçeve Görüşmesi)

  • Ana
  • Diğer
  • En İyi 12 Sahte Görüşme Sorusu (Alaycı Çerçeve Görüşmesi)

top 12 mockito interview questions

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

Mockito Alaycı Röportajı Kırmak için En Sık Sorulan Mockito Röportaj Soruları:

Önceki eğitimimizde öğrendik Özel, Statik ve Boş alay yöntemleri . Baştan sona okuyun Mockito'da eğitimleri tamamlayın Mockito çerçevesinin net bir şekilde anlaşılması için.

Bu makale, Mockito Mocking çerçevesi hakkında en sık sorulan tipik mülakat sorularını kapsar.

Her geliştiricinin veya Kalite Güvencesi'nin, çoğu beyaz kutu testini (veya birim testlerini) kolaylıkla yazmak ve gelişmiş kod kapsamı ve uygulamada daha fazla güven için bağımlılıklarla dalga geçmek için Mocking temellerini bilmesi beklenir.

Mockito mülakat soruları

Ayrıntılı Cevaplarla En Popüler Mockito Röportaj Soruları

Mocking Frameworks hakkında en sık sorulan sorular aşağıda listelenmiştir.

S # 1) Neden dalga geçmeye ihtiyacımız var?

Cevap: İzolasyon altında kodun birim testine yardımcı olan ve testi yüksek oranda tekrarlanabilir ve öngörülebilir kılan pek çok alay konusu vardır.

Alay etmek genellikle şu durumlarda gereklidir:

için) Test edilen bileşenin henüz uygulanmamış bağımlılıkları var veya uygulama devam ediyor.

İyi bir örnek, daha sonra bir noktada kullanılabilecek bir REST API uç noktası olabilir, ancak bunu bir bağımlılık yoluyla kodda kullandınız.

Artık gerçek uygulama hala mevcut olmadığından, çoğu zaman bu API'nin beklenen yanıtının ne olduğunu gerçekten biliyorsunuz. Mocks, bu tür entegrasyonları test etmenize olanak tanır.

b) Bileşen, sistemdeki durumu günceller.

Misal: DB çağrıları - DB'nizi sadece test amaçlı olan verilerle güncellemek istemezsiniz. Bu, verilerin bozulmasına neden olabilir, ayrıca, DB'nin kullanılabilirliği, test yürütüldüğünde başka bir sorundur.

Bu nedenle, bu tür davranışlardan kaçınmak için, DB çağrıları test edilen bileşende alay edilebilir. Bu nedenle, DB ve test edilen bileşenin doğrudan bir bağlantısı yoktur.

S # 2) doReturn ve thenReturn arasındaki fark.

Cevap: Mockito, taslak oluşturmak için iki farklı sözdizimi sağlar:

  • doReturn ve ardındanReturn
  • doNothing (o zaman değil)
  • doThrow ve thenThrow

Bu yöntemlerin her ikisi de saplamalar oluşturur ve saplamalar oluşturmak / ayarlamak için kullanılabilir ve zaman zaman birbirinin yerine kullanılabilir.

android telefonlar için en iyi casus uygulamaları

Peki bunların ikisi de nasıl farklı?

için) ThenReturn stubbing yöntemi, stub'ları kurmanın tür güvenli bir yoludur. Bunun esasen anlamı, sizin de saplamak istediğiniz dönüş türlerine karşı bir derleme zamanı kontrolü yapmasıdır.

Bunu bir örnekle anlayalım:

Bir yöntem varsayalım getItemDetails açık mockedItemService türünde bir nesne döndüren ItemSku. Böylece thenReturn, ItemSku türünden başka bir şey iade edemezsiniz, ancak doReturn ile saplamayı herhangi bir şey döndürmek üzere ayarlayabilirsiniz ve yürütme sırasında test başarısız olur (veya bir istisna atar).

// İşler

when (mockedItemService.getItemDetails(123)).thenReturn(new ItemSku());

// derleme zamanı istisnası atar

when (mockedItemService.getItemDetails(123)).thenReturn(expectedPrice);

// doReturn ile, derleme güvenli olmadığı için her iki saplama kurulumu da çalışır.

// burada hala çalışan ve herhangi bir derleme zamanı uyarısı vermeyen double türünde bir nesne döndürmeye çalışıyoruz.

doReturn (expectedPrice).when(mockedItemService.getItemDetails(123)); doReturn (new ItemSku()).when(mockedItemService.getItemDetails(123));

b) Saplamaya giden bu 2 yol arasındaki bir diğer önemli fark Mocked nesneler içindir, derleme güvenliği dışında çok fazla fark yoktur.

Ancak, Casus nesneler için, 'thenReturn' türü saplama kurulumu çalışmayacaktır, çünkü stubbed yanıtı çağrı olarak geri dönmeden önce gerçek yöntemin çağrılmasıyla sonuçlanacaktır, bir Sahte değil, ancak gerçek bir nesne örneğini saran Spy'da .

Diyelim ki, adında bir casus var spiedObject ve bir tamsayı döndüren bir testMethod yöntemine sahiptir, daha sonra bunun üzerine bir saplama kurmak için thenReturn yerine doReturn kullanmanız gerekecektir.

doReturn (10).when(spiedObject.testMethod());

S # 3) Bir casus ne zaman ve neden kullanılmalıdır?

Cevap: Casus, Mockito tarafından desteklenen bir tür kısmi taklittir.

Bu, esasen şu anlama gelir:

için) Sahte kurulum yapılmadığında, casus üzerindeki herhangi bir etkileşim, gerçek yöntemleri çağırmaya neden olur. Ancak yine de casus nesneyle etkileşimleri doğrulamanıza izin verir - aslında bir yöntem çağrıldı, yöntemin kaç kez çağrıldığı, yöntemin çağrıldığı argümanlar nelerdi vb.

b) Kısmi taklitler kurma esnekliği sağlar.

Örneğin, Yöntem1 ve yöntem2 olmak üzere 2 yöntemi olan bir nesneniz varsa ve yöntem1'in çağrılmasını ve yöntem2'nin alay edilmesini istiyorsanız. Casuslar bu tür bir kurulum sağlar.

Dolayısıyla, basit terimlerle bir sahte ve saplama arasındaki fark şudur: bir örnek bir türden bir taklit oluşturulurken, bir saplama, sınıf nesnesinin gerçek bir örneğini sarar.

S # 4) Mockito kullanılarak neden statik yöntemlerle dalga geçilemez?

döngüsel bağlantılı liste c ++

Cevap: Statik yöntemler, sınıfın belirli bir örneği ile değil, sınıfın kendisiyle ilişkilidir. Bu, sınıfın tüm örneklerinin / nesnelerinin statik yöntemin aynı örneğini kullandığı anlamına gelir.

Statik yöntemler daha çok prosedürel kod gibidir ve çoğunlukla eski sistemlerde genel olarak kullanılır.

Sahte kitaplıklar tipik olarak, çalışma zamanında ya arayüzler aracılığıyla ya da kalıtım yoluyla dinamik örnek oluşturarak taklitler oluşturur ve statik yöntem herhangi bir belirli örnekle ilişkilendirilmediğinden, alay çerçevelerin (mockito, kolay alay, vb.) Statik yöntemlerle dalga geçmesi mümkün değildir.

Statik yöntemler için desteği olan PowerMock gibi çerçeveler, statik yöntemlerle alay etmek için çalışma zamanında bayt kodu manipülasyonu gerçekleştirir.

S # 5) Sahte çağrının yapıldığını doğrulamaya ne gerek var?

Cevap: Alay edilen bir nesnede (veya casusluk yapılan bir örnekte) bir saplama ayarlamak, stub edilen kurulumun çalıştırılıp başlatılmadığını garanti etmez.

'Doğrulama' eşleştiricileri, ayarlanmış olan saplamanın gerçekten çağrılıp çağrılmadığını, çağrının kaç kez yapıldığını, stubbed yöntemin hangi argümanlarla çağrıldığını vb. Doğrulamak için bir olanak sağlar.

Temelde, test kurulumunu ve beklenen sonucu daha sağlam bir şekilde doğrulamamıza olanak tanır.

S # 6) İyi test edilebilir kod nedir?

Cevap:

Test edilebilir kod (birimin kolayca test edilebileceği anlamına gelir) hakkında birkaç nokta şunları içerir:

  • Daha az bağımlılık veya sıkı bağlantı - Misal: Bağımlılıklar doğrudan örneklenmek yerine enjekte edilmelidir.
  • SRP'ye (Tek Sorumluluk İlkesi) uygun kod - Bu, esas olarak, sınıfın değişmesi için birden fazla nedeni olmaması gerektiği anlamına gelir. SRP'ye bağlılık, sınıfların kendine bağımlı olmasını önler ve kodu tutarlı ve temiz tutar.
  • Statik yöntemlerin ve son sınıfların daha az / Minimum kullanımı - Bunlar genellikle kod kokularını gösterir ve çoğunlukla eski kodla ilişkilendirilmiştir.

S # 7) Mockito'nun sınırlamaları nelerdir?

Cevap: Mockito, java tabanlı projelerin çoğu için tercih edilen bir çerçevedir. Uygulaması, okuması ve anlaması kolaydır.

İşlevsellik açısından bazı dezavantajlar veya sınırlamalar şunlardır:

  • Statik yöntemlerle alay edememesi.
  • Oluşturucular, özel yöntemler ve son sınıflar alay edilemez.

S # 8) Özel ve Statik yöntemlerle alay etmeyi hangi çerçeveler destekleyebilir?

Cevap: PowerMockito (Mockito çerçevesinin uzantıları), JMockit, vb. Gibi çerçeveler, özel ve statik yöntemlerle alay etmek için araçlar sağlar.

S # 9) Java 8'de Arayüzde varsayılan yöntemleri alay etme / Stubbing.

Cevap: Java 8’in Arayüzdeki varsayılan yöntemler uygulamasıyla Mockito, bu tür varsayılan yöntemlerle alay etmek için hazır destek sağlar. (Lütfen bu desteğin Mockito 2'den itibaren sunulduğunu unutmayın).

Bu yöntemler, bir sınıfın veya arayüzün diğer herhangi bir yöntemi gibi alay edilebilir / taklit edilebilir.

S # 10) Mockito'da saplama çağrılarının sırası nasıl doğrulanabilir?

Cevap: Taklitlerin çağrıldığı sırayı doğrulamak istediğinizde Mockito’nun ' Sırayla ”Arayüzü kullanılabilir.

Test sırasında, basitçe bir Inorder nesnesi kurmanız / oluşturmanız gerekir, bu nesnelerin sırasının belirlenmesi gereken sahte nesnelerin bir listesini (aynı modelde birden fazla yöntem varsa ve ihtiyaç duyulan başka bir model yoksa) doğrulanması için alay konusu sınıftan yalnızca bir kez bahsetmek yeterlidir).

Bir InOrder nesnesini tanımlayan ve mockDatabaseImpl'nin 2 oluşumundan bahseden aşağıda verilen testi düşünün.

@Test public void calculateSumAndStore_withValidInput_verifyMockOrder() { // Arrange studentScores = new StudentScoreUpdates(mockDatabaseImpl); int() scores = {60,70,90}; Mockito.doNothing().when(mockDatabaseImpl).updateScores(anyString(), anyInt()); Mockito.doReturn('A').when(mockDatabaseImpl).getGrade(anyInt()); InOrder inorder = inOrder(mockDatabaseImpl); // Act studentScores.calculateSumAndStore('Student1', scores); // Assert inorder.verify(mockDatabaseImpl).updateScores(anyString(),anyInt()); inorder.verify(mockDatabaseImpl).getGrade(anyInt()); }

Ayrıca, referans olarak, test edilen yöntemin kodunu listelemek, test yürütme sırasını anlamak için yardımcı olacaktır:

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); databaseImpl.getGrade(total); }

Yukarıda görüldüğü gibi, databaseImpl önce updateScores'ı ve sonra getGrade'i çağırır.

Bu nedenle, Mockito kullanarak bir birim testi yazıyorsanız, bunun için ve databaseImpl'deki çağrıların sırasını sağlamanız gerekiyorsa, test koduna bakın ve önermelerin beklenen sıraya göre yapıldığından emin olun.

Yukarıdaki örnekte, iddiaların sırasını değiştirirsem, 'VerificationInOrderFailure' dışında testin başarısız olmasına neden olur.

Onaylama sırasını değiştirdikten sonra, kod aşağıda gösterildiği gibi görünür:

@Test public void calculateSumAndStore_withValidInput_verifyMockOrder() { // Arrange studentScores = new StudentScoreUpdates(mockDatabaseImpl); int() scores = {60,70,90}; Mockito.doNothing().when(mockDatabaseImpl).updateScores(anyString(), anyInt()); Mockito.doReturn('A').when(mockDatabaseImpl).getGrade(anyInt()); InOrder inorder = inOrder(mockDatabaseImpl); // Act studentScores.calculateSumAndStore('Student1', scores); // Assert inorder.verify(mockDatabaseImpl).updateScores(anyString(),anyInt()); inorder.verify(mockDatabaseImpl).getGrade(anyInt()); }

Yukarıdaki test yürütmesi, şu türle bir istisna atar:

'VerificationInOrderFailure' org.mockito.exceptions.verification.VerificationInOrderFailure:
Sipariş hatasında doğrulama
Aranıyor ama çağrılmamış:
mockDatabaseImpl.updateScores (
isA (java.lang.String),
isA (java.lang.Integer)

S # 11) Ardışık yöntem çağrılarına karşı birden çok değer döndürme

Cevap: Aynı stubbed yönteminin birden çok çağrısı için farklı değerler döndürmek üzere Mockito, aşağıda verildiği gibi 3 yaklaşım sağlar:

için) Virgülle ayrılmış olarak: Bu, thenReturn ile çalışır.

Örneğin , yukarıdaki kod örneğini alarak, yinelemelerin sırasına bağlı olarak farklı değerler döndürecek olan - getGrade yöntemi için ardışık saplama kurmaya çalışalım:

when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A','B', 'C');

Bu, test edilen yöntemde getGrade yöntemleri çağrıldığında, ilk çağrının 'A', ikinci çağrının 'B' şeklinde döneceği anlamına gelir.

b) Ardışık sonra Geri Dön: Bu, thenReturn ifadeleriyle zincirlenmiş bir yaklaşımdır. Aynı örneğe zincirleme aramaların uygulanması aşağıda gösterildiği gibi görünecektir.

when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A').thenReturn('B').thenReturn('C');

c) Ardışık doReturn: Son yaklaşım, yukarıdaki gibi zincir biçiminde doReturn kullanmaktır.

doReturn ('A').doReturn('B').doReturn('C').when(mockDatabaseImpl).getGrade( anyInt ())

S # 12) Farklı alay çerçevesi türleri nelerdir ve bunlar nasıl çalışır?

Cevap: Mocking çerçevesinin türleri ve nasıl çalıştıkları aşağıda açıklanmıştır.

Genel olarak 2 alay çerçevesi kategorisi vardır:

  1. Proxy tabanlı - Misal, Mockito, EasyMock vb.
  2. Bayt kodu tabanlı - Misal, PowerMock, JMockit vb.

Şimdi bu iki çerçeveyi farklı parametreler üzerinde karşılaştıralım.

Proxy tabanlıBayt kodu tabanlı
BasitçeDaha basit ve kullanımı kolayKarmaşık sahte kurulum mantığı içerebilir
Yaratma moduAslında sınıf / arayüz örneğini gerektirmeyen bir proxy veya sahte nesne oluşturulurEsasen nesneler oluşturmayı içerir ve çalışma zamanında alay edilen / stubed davranış için örnekleri işler.
İşlevsellikAlay sınıfları ve arayüzlerSınıflara ve arayüzlere ek olarak, statik yöntemler, son sınıflar vb.
Java bağımlılığıJava sürümlerine çok sıkı bağlı değilBu çerçeveler bayt kodu manipülasyonu içerdiğinden, sıkı bir şekilde birleştirilirler ve java sürümleri arasında geriye / ileriye doğru uyumlu olmayabilir.
ÖrneklerMockito, EasyMock vb.PowerMock, JMockit vb.

Sonuç

Bu makalede ele alınan içerik, Mocking çerçeveleri ve özellikle Mockito mülakat hazırlığı hakkında temel tartışmalara hizmet eder.

Kapsanan soruların teorik olarak anlaşılmasına ek olarak, bu çerçeveleri öğrenmeyi daha eğlenceli ve ilginç hale getiren gerçek kod örnekleri yapmayı da denemelisiniz.

Umarım bu Mockito serisindeki tüm eğitimlerden keyif almışsınızdır.

chrome için en iyi reklam engelleyici nedir

Mutlu Öğrenme.

PREV Eğitimi | FIRST Eğitimi

Önerilen Kaynaklar

^