2011-04-08 18 views
5

Bir yay uygulamam var ve bunun gibi bir denetleyicide üniter bir test oluşturmak istiyorum. Sorun, Wrapper sınıfının özel bir iç sınıf olmasıdır, bu yüzden Wrapper testte anlaşılmamıştır. Kontrolör sınıfını değiştirmeden Mockito ile alay etmek mümkün mü? Nesnenin bir örneğini almak için prepareData() kullanabilirim, ancak bu nesneyi alay etmek için kullanılıp kullanılamayacağını bilmiyorum.Özel bir iç sınıfla alay etme

Teşekkür

@Controller 
public class Controller { 

    private class Wrapper { 
     private Object1 field1; 
     private Object2 field2; 
     private Object1 method1(){ 
      ... 
     } 
     private Object2 method1(){ 
      ... 
     } 
    } 

    @ModelAttribute("data") 
    public Wrapper prepareData() { 
      return new Wrapper(); 
} 

    public String save(@ModelAttribute("data") Wrapper wrapper, BindingResult result, Model model){ 
     ... 
    } 
} 

Yani benim test ben senin test yöntemlerinin üzerinde bu

@Test 
public void usernameEmpty(){ 

    BindingResult result = Mockito.mock(BindingResult.class); 
    Model model = Mockito.mock(Model.class); 
    Wrapper data = //how to mock it 
    when(data.method1()).then(new Foo1()); 
    when(data.method2()).then(new Foo2()); 
    String returned = controller.save(data, result, model); 
    .... 
} 
+3

Bunu neden yapmak istediğini soruyorum. Muhtemelen yanlış kodu sınayacaksınız. İçsel sınıf bağımlılıklara sahipse (muhtemelen kontrolörden mi alınır?) Bunları alay edin. Bekleyin? Kodunuz derleniyor mu? Wrapper özel sınıfsa, bunu genel bir yönteme karşı argüman olarak kullanabilir misiniz? –

+0

@Martinho Fernandes Testte yeniyim. Ben sadece kaydetme yönteminde bir test yapmak istedim, bu yüzden Wrapper nesnesine alay etmem gerekiyordu, böylece bazı yöntemler üzerinde çağrıldığında geri dönüş nesnelerini tanımlayabiliyordum. Evet, kontrolör derler (Test, ancak bu problem değil - testte Wrapper sınıfını kullanamıyorum). Belki bunu yapmanın daha iyi bir yolu vardır. – Javi

+0

Java beni tekrar şaşırttı (negatifte). Bu, elimde bir Java derleyicisi olmadan bana yardımcı olmak için güçsüz kılıyor :(Her neyse, izin verse bile, özel bilginin gerektirdiği bir kamu yöntemine sahip olmanın iyi bir tasarım olduğunu düşünmüyorum. Kapsüllenmeyi nasıl kıracaksınız. Bu gerçek gerçek kodda bu yöntemi kullanın? Mümkün mü –

cevap

8

gibi bir şey olurdu, ama bütün sınıf davranışı test eder. İç sınıfınız özel ise o zaman bir uygulama detayıdır. Testin bilmemesi gereken bir şey. İçsel sınıfta çok fazla davranış var ve bunu bağımsız olarak test etmek istiyorsun belki de onu kamuya açmalı ve bu sınıftan ayrı olmalısın.

Belki düşünürsünüz: ama sonra ... test etmek için çok fazla kod (çok büyük bir bölünmez şey), daha küçük bir şeyi test edemiyorum? İyi evet. Test Tahrikli Geliştirme, daha fazla test eklediğinizde minimum bir uygulama yapmak ve daha fazla kod eklemek için yetkilendirir. Yani bazı testler ve minimum uygulamalarla başlarsınız ve testler tüm spesifikasyonlara ve kodun tüm uygulamalarına sahip olana kadar her ikisini de geliştirirsiniz. Bu nedenle özel iç sınıflar için endişelenmeyin. Sınıf sözleşmenizi test edin!

+0

Ve birim testi ile iyi şanslar! Çok fazla güven ve bu şeyi (inadvertidally) kırmadan değişme yeteneği verir! – helios

+0

Çok iyi değil - entegrasyon testi olacak. Test odaklı geliştirmenin temel prensiplerinden birini kırdınız - test basit olmalı! – user710818

+0

Evet. Fakat TDD bir geliştirme metodolojisidir: önce yazma testi yapın, sonra kodu yazın. Bu durumda OP, başka bir tasarım (daha basit ve daha modüler) alabilir ve özel bir iç sınıf elde edemez. Bu durumda, sadece var olan bir kodu test ediyor. Dedi ki: Basit bir test olmadığına katılıyorum, fakat özel bir iç sınıf konteyner sınıfından çıkarılamaz, bu yüzden basit değil, bir entegrasyon testi IMHO değil (her neyse, önemli kısım "test" dir) – helios

İlgili konular