2012-09-14 29 views
5

मैं एक यूनिट परीक्षण लिखने की कोशिश कर रहा हूं जिसे किसी विधि को बुलाया गया है या नहीं। मैं जुनीट, मॉकिटो और पावरमोक का उपयोग कर रहा हूं।जांच के तहत सिस्टम पर विधि कहां से कॉल की जाती है (नकली नहीं)

 
public class Invoice 
{ 

    protected void createInvoice() 
    { 
    // random stuff here 
    markInvoiceAsBilled("57"); 
    } 

    protected void markInvoiceAsBilled(String code) 
    { 
    // marked as billed 
    } 
} 

तो, यहां परीक्षण के तहत मेरा सिस्टम Invoice है। मैं इस परीक्षण चल रहा हूँ:

 
    public class InvoiceTest 
    { 
    @Test 
    public void testInvoiceMarkedAsBilled() 
    { 
     Invoice sut = new Invoice(); 
     Invoice sutSpy = spy(sut); 

     sut.createInvoice(); 

     // I want to verify that markInvoiceAsBilled() was called 
    } 
    } 

यह उदाहरण सिर्फ वास्तविक कोड कैसा दिखता का एक उदाहरण है ....

मेरे समस्या यह है कि mockito कहते हैं अगर एक विधि कहा जाता है कि आप केवल पुष्टि कर सकते हैं है एक मॉक ऑब्जेक्ट पर ... लेकिन मैं इस ऑब्जेक्ट को नकल नहीं करना चाहता, क्योंकि यह मेरी ऑब्जेक्ट टेस्ट के तहत है। मुझे पता है कि आप वस्तु आप परीक्षण कर रहे हैं पर जासूसी कर सकते हैं, तो यहाँ मैं क्या करने की कोशिश की है:

 

    verify(sutSpy).markInvoiceAsBilled("57"); 

मैं क्या संभव नहीं करने के लिए कोशिश कर रहा हूँ है? या मैं बस इसके बारे में गलत तरीके से जा रहा हूँ?

सभी को धन्यवाद :)

उत्तर

5

मुझे यकीन है कि आप क्या करना प्रयास कर रहे हैं चीजों के बारे में जाने के लिए सबसे अच्छा तरीका है अगर नहीं हूँ।

मैं पुष्टि करने Invoice.createInvoice() एक आंतरिक, निजी विधि markInvoiceAsBilled() कॉल के साथ अपने आप को चिंता का विषय नहीं है - इसके बजाय परीक्षण है कि फोन करने createInvoice() के आपकी अपेक्षानुसार चालान वस्तु की स्थिति में परिवर्तन - यानी, कि status अब BILLED या कुछ इसी तरह है ।

दूसरे शब्दों में - परीक्षण नहीं है क्या तरीकों createInvoice() द्वारा कहा जाता है - परीक्षण इस विधि बुला के बाद, वस्तु की राज्य आप क्या उम्मीद है।

0

मै मैट-बी के उत्तर से सहमत हूं। ऐसा कहा जा रहा है कि, उपयोग के मामले और विधि की जटिलता के आधार पर, आप अपनी इकाई को फिर से डिजाइन कर सकते हैं ताकि इसका परीक्षण किया जा सके।

उदाहरण के लिए कहें कि आपकी वस्तु अधिक जटिल हो गई है, उदा।

public A { 
    public a() { 
    b(); 
    c(); 
    } 

    public b() { /** hairy code, many branches to test */ } 
    public c() { /** hairy code, many branches to test */ } 
} 

कवर परीक्षण और परीक्षण के साथ ग के साथ ख सीधी-सपाट है, लेकिन एक को कवर एक परेशानी की तरह लग जब से तुम ख तरीकों और ग पर निर्भर करेगा।

बजाय विचार करें इस डिजाइन

public A { 
    private final Dep mDep; 

    public a() { 
    mDep.b(); 
    mDep.c(); 
    } 

    public b() { 
    mDep.b(); 
    } 

    public c() { 
    mDep.c(); 
    } 

    // dependency abstraction we create to help test 
    static class Dep { 
    public b() { /** hairy code, many branches to test */ } 
    public c() { /** hairy code, many branches to test */ } 
    } 
} 

अब, A.a, A.b और A.c परीक्षण बस (के बीच जो कुछ भी विधि करता है) अपने mDep कहा जाता है को सत्यापित करने की आवश्यकता है। अलग-अलग, आप A.Dep.b और A.Dep.c विधियों का परीक्षण करते हैं।