2008-09-29 7 views
8

लोग टीसीपी क्लाइंट (या टीसीपी क्लाइंट जैसी चीजें) का मज़ाक उड़ाते हैं?टीडीडी और मॉकिंग टीसीपी क्लाइंट

मेरे पास एक सेवा है जो टीसीपी क्लाइंट में ले जाती है। क्या मुझे इसे किसी और चीज में लपेटना चाहिए? मुझे इस बात से कैसे संपर्क करना चाहिए?

उत्तर

22

नकली कक्षाओं में आने पर जब परीक्षण अनुकूल नहीं होते हैं (यानी किसी भी इंटरफ़ेस/विधियों को लागू नहीं किया जाता है), तो आप शायद Adapter डिज़ाइन पैटर्न का उपयोग करना चाहेंगे।

इस पैटर्न में आप एक रैपिंग क्लास जोड़ते हैं जो एक इंटरफ़ेस लागू करता है। इसके बाद आपको इंटरफ़ेस का मज़ाक उड़ाया जाना चाहिए, और यह सुनिश्चित करना चाहिए कि आपका सभी कोड असंगत कंक्रीट क्लास के बजाय उस इंटरफ़ेस का उपयोग करता है। यह कुछ ऐसा दिखाई देगा:

public interface ITcpClient 
{ 
    Stream GetStream(); 
    // Anything you need here  
} 
public class TcpClientAdapter: ITcpClient 
{ 
    private TcpClient wrappedClient; 
    public TcpClientAdapter(TcpClient client) 
    { 
    wrappedClient = client; 
    } 

    public Stream GetStream() 
    { 
    return wrappedClient.GetStream(); 
    } 
} 
+0

यह सही है! धन्यवाद! –

+0

+1 सर्वोत्तम स्पष्टीकरण प्लस अच्छा सरल उदाहरण – Ahmad

+0

धन्यवाद @ फ़ंकिमशरूम, निश्चित –

2

एडाप्टर पैटर्न का उपयोग करना समस्या के लिए निश्चित रूप से मानक टीडीडी दृष्टिकोण है। हालांकि, आप टीसीपी कनेक्शन के दूसरे छोर को भी बना सकते हैं और आपके टेस्ट हार्नेस ड्राइव को भी कर सकते हैं।

आईएमओ एडाप्टर क्लास का व्यापक उपयोग डिज़ाइन के सबसे महत्वपूर्ण हिस्सों को खराब करता है, और परीक्षण के बहुत सारे सामान को भी हटा देता है जो वास्तव में संदर्भ में परीक्षण किया जाना चाहिए। इसलिए विकल्प परीक्षण के तहत सिस्टम को शामिल करने के लिए अपने परीक्षण मचान का निर्माण करना है। यदि आप ग्राउंड अप से अपने परीक्षण बना रहे हैं, तो भी आप किसी दिए गए वर्ग या फ़ंक्शन की विफलता के कारण को अलग करने की क्षमता प्राप्त करेंगे, यह केवल अलगाव में नहीं होगा ...

+0

यह परीक्षण को एकीकरण परीक्षण करेगा, न कि यूनिट-टेस्ट। यह धीमा हो जाएगा, और असफल होने की संभावना अधिक है। ऐसा नहीं है कि इसमें कुछ भी गलत है, आपको बस इसके बारे में पता होना चाहिए (उदाहरण के लिए, आपके सीआई समाधान में)। –

5

मुझे लगता है @ हिचहिकर सही रास्ते पर है, लेकिन मैं चीजों को सारणीबद्ध करने के बारे में सोचना भी पसंद करता हूं जैसे कि एक कदम आगे।

मैं सीधे टीसीपी क्लाइंट को नकल नहीं करूँगा, क्योंकि यह अभी भी अंतर्निहित कार्यान्वयन के लिए बहुत करीब से जुड़ा होगा, भले ही आपने परीक्षण लिखे हों। यही है, आपका कार्यान्वयन विशेष रूप से एक टीसीपी क्लाइंट विधि से जुड़ा हुआ है। व्यक्तिगत रूप से, मैं कुछ इस तरह की कोशिश करेंगे:

[Test] 
    public void TestInput(){ 

     NetworkInputSource mockInput = mocks.CreateMock<NetworkInputSource>(); 
     Consumer c = new Consumer(mockInput); 

     c.ReadAll(); 
    // c.Read(); 
    // c.ReadLine(); 

    } 

    public class TcpClientAdapter : NetworkInputSource 
    { 
     private TcpClient _client; 
     public string ReadAll() 
     { 
      return new StreamReader(_tcpClient.GetStream()).ReadToEnd(); 
     } 

     public string Read() { ... } 
     public string ReadLine() { ... } 
    } 

    public interface NetworkInputSource 
    { 
     public string ReadAll(); 
     public string Read(); 
     public string ReadLine(); 
    } 

इस कार्यान्वयन आप टीसीपी से संबंधित विवरण पूरी तरह दसगुणा होगा (कि अगर एक डिजाइन लक्ष्य है), और आप कर सकते हैं यहां तक ​​कि मूल्यों की एक हार्ड कोडित सेट से परीक्षण इनपुट में पाइप , या एक परीक्षण इनपुट फ़ाइल। यदि आप लंबे समय तक अपने कोड का परीक्षण करने के लिए सड़क पर हैं तो बहुत हाथ।