2012-06-25 11 views
5

यह सत्यापित करना आसान है कि मॉकिटो में एक मॉक ऑब्जेक्ट पर विशिष्ट इंटरैक्शन (विशिष्ट विधि कॉल) हुई, और यह जांचने के लिए है कि कोई इंटरैक्शन बिल्कुल नहीं हुआ है। मान लीजिए कि मैं info(), warn(), error() आदि जैसी विधियों के साथ एक लॉगर की तरह एक इंटरफेस का परीक्षण कर रहा हूं। एक विशिष्ट परिदृश्य में मुझे पता है कि इन तरीकों में से एक को बुलाया जाना चाहिए, लेकिन मुझे वास्तव में परवाह नहीं है। क्या यह जांचने का एक कॉम्पैक्ट तरीका है कि नकली ऑब्जेक्ट के साथ कोई भी बातचीत बिना किसी विधि को निर्दिष्ट करने की आवश्यकता के बिना हुई है? या शायद इस तरह की एक तंत्र जरूरी नहीं है क्योंकि इसका परीक्षण करने का "मॉकिटो रास्ता" मैं कल्पना करता हूं उससे अलग होगा?क्या मैकिटो का उपयोग कॉम्पैक्ट तरीके से मनमाने ढंग से बातचीत करना संभव है?

उत्तर

1

यदि आप परीक्षण के तहत कक्षा से अपने लॉगर ऑब्जेक्ट के निर्माण को बाहरी कर सकते हैं, तो कोई कारण नहीं है कि आप लॉग इंटरफ़ेस का अपना परीक्षण कार्यान्वयन क्यों नहीं लिख सकते हैं जो रिकॉर्ड करेगा कि कौन सी विधियों का उपयोग किया गया था और इसे इंजेक्ट किया गया था आपका परीक्षण सेटअप

नकली पुस्तकालय बहुत अच्छे काम करते हैं, लेकिन कभी-कभी ऐसे कोने के मामले होते हैं जैसे आपको पता चला है कि वे आपकी आवश्यकताओं को कवर नहीं कर सकते हैं।

आप इस तरह के परीक्षण के लिए अपने स्वयं के कार्यान्वयन लिखते हैं, और yourt परीक्षण वर्ग में यह परीक्षण के अंतर्गत इंजेक्षन है, तो आप getCount() > 0

public class LoggerTestSupportImpl implements ILogger { 

    private int count = 0; 

    @Override 
    public int getCount() { 
     return count; 
    } 

    @Override 
    public void info(String message) { 
     count++;  
    } 

    @Override 
    public void warn(String message) { 
     count++;  
    } 
} 
+1

पर जोर कर सकते हैं यह ठीक है कि कैसे मैं अपने वर्ग अब तक का परीक्षण किया गया है, मैं बस सोच रहा था कि क्या मॉकिटो मुझे सभी तरीकों के लिए छोटे कार्यान्वयन लिखने से बचा सकता है। –

+0

मैं कहूंगा कि आप समझदार चीज़ मीकल कर रहे हैं। मॉकिटो इस तरह के परीक्षण का समर्थन नहीं करता है। केविन द्वारा उल्लिखित 'ArgumentCaptor' मार्ग को नीचे जाने का आपका एकमात्र विकल्प है, लेकिन इससे आपके परीक्षण वर्गों में बहुत सारे "शोर" होते हैं। – Brad

+0

सहमत है कि यह थोड़ा शोर है, लेकिन अधिकांश शोर घोषणाओं और पहले विधि के लिए स्थानीयकृत है, और यदि आप एकाधिक टेस्ट विधियों में उपयोग किया जाना है तो भी कैप्चर को क्लास लेवल घोषणाओं में जोड़ सकते हैं (यदि संदेश तक पहुंच न हो तो भी आवश्यक नहीं है) । मॉकिटो का उपयोग करने के बारे में अच्छी बात यह है कि आपके पास पहले से ही पूर्ण लॉगिंग एपीआई तक पहुंच है। अपने उदाहरण में ऐसा करने के लिए आपको अपने हाथ से चलने वाले मॉक की क्षमताओं का विस्तार करना होगा (लॉग इन संदेशों के मनमानी # को कैप्चर/पुनर्प्राप्त करें) लेकिन सरल जरूरतों के लिए आपका तरीका सरल, क्लीनर, * और * पुन: प्रयोज्य लगता है, इसलिए वे हैं आपके दृष्टिकोण के लिए कुछ प्लस। –

2
log4j साथ

, लकड़हारा मैं निम्नलिखित सेटअप करना परीक्षण करने के लिए:

verifyZeroInteractions(log4jAppender); 

या

verify(log4jAppender).doAppend(any(LoggingEvent.class); 

हैं:

@Mock private Appender log4jAppender; 
private Logger logger; 

@Before 
public void setup() { 
    MockitoAnnotations.initMocks(this); 

    Logger root = Logger.getRootLogger(); 
    if (!root.getAllAppenders().hasMoreElements()) { 
     // No appenders means log4j is not initialized! 
     BasicConfigurator.configure(); 
    } 
    logger = Logger.getLogger(MyClassWhichLogs.class); 
    logger.addAppender(log4jAppender); 
} 

और फिर अपने परीक्षण में मैं निम्न कार्य करें आपको लॉग किए गए मानों का परीक्षण करने की आवश्यकता है, आप इसके बजाय एक कैप्चर प्रदान कर सकते हैं:

ArgumentCaptor<LoggingEvent> logCaptor = ArgumentCaptor.forClass(LoggingEvent.class); 
verify(log4jAppender).doAppend(logCaptor.capture()); 
assertTrue(logCaptor.getValue().contains("my text to match"); 

हालांकि यह सामान्यीकृत प्रश्न का उत्तर नहीं देता है (मुझे नहीं लगता कि आप जो खोज रहे हैं वह मौजूद है), यह लॉगिंग परीक्षण के लिए इस विशिष्ट समस्या को हल कर सकता है।

संबंधित मुद्दे