c# एक निजी विधि को इकाई के लिए सार्वजनिक करना... यह अच्छा विचार है?




java unit-testing (20)

ध्यान दें:
यह उत्तर मूल रूप से इस प्रश्न के लिए पोस्ट किया गया था कि क्या यूनिट परीक्षण अकेले कभी गेटर्स के माध्यम से निजी उदाहरण चर को उजागर करने का एक अच्छा कारण है? जो इस एक में विलय कर दिया गया था, इसलिए यह वहाँ प्रस्तुत usecase के लिए विशिष्ट एक बालक हो सकता है।

एक सामान्य कथन के रूप में, मैं आमतौर पर परीक्षण के लिए आसान बनाने के लिए "उत्पादन" कोड को फिर से तैयार करने के लिए हूं। हालाँकि, मुझे नहीं लगता कि यह एक अच्छी कॉल होगी। एक अच्छी इकाई परीक्षण (आमतौर पर) को केवल अपने दृश्य व्यवहार के बारे में, वर्ग के कार्यान्वयन विवरणों की परवाह नहीं करनी चाहिए। परीक्षण के लिए आंतरिक स्टैक को उजागर करने के बजाय, आप यह परीक्षण कर सकते हैं कि कक्षा आपके द्वारा first() या last() कॉल करने के बाद अपेक्षा के पन्नों को वापस कर देती है।

उदाहरण के लिए, इस छद्म कोड पर विचार करें:

public class NavigationTest {
    private Navigation nav;

    @Before
    public void setUp() {
        // Set up nav so the order is page1->page2->page3 and
        // we've moved back to page2
        nav = ...;
    }

    @Test
    public void testFirst() {
        nav.first();

        assertEquals("page1", nav.getPage());

        nav.next();
        assertEquals("page2", nav.getPage());

        nav.next();
        assertEquals("page3", nav.getPage());
    }

    @Test
    public void testLast() {
        nav.last();

        assertEquals("page3", nav.getPage());

        nav.previous();
        assertEquals("page2", nav.getPage());

        nav.previous();
        assertEquals("page1", nav.getPage());
    }
}

https://code.i-harness.com

मॉडरेटर नोट: यहां पहले से ही 39 उत्तर पोस्ट किए गए हैं (कुछ हटा दिए गए हैं)। अपना उत्तर पोस्ट करने से पहले, विचार करें कि आप चर्चा में कुछ सार्थक जोड़ सकते हैं या नहीं। आप संभावना से अधिक दोहरा रहे हैं कि किसी और ने पहले ही कहा है।

मैं कभी-कभी अपने आप को एक कक्षा में सार्वजनिक करने के लिए एक निजी विधि बनाने की जरूरत महसूस करता हूं ताकि इसके लिए कुछ यूनिट टेस्ट लिख सकूं।

आमतौर पर ऐसा इसलिए होता है क्योंकि विधि में कक्षा में अन्य विधियों के बीच साझा किए गए तर्क होते हैं और यह तर्क को अपने दम पर परखने के लिए तीखा होता है, या कोई अन्य कारण संभव हो सकता है कि मैं समसामयिक धागों में प्रयुक्त तर्क का परीक्षण करना चाहता हूं बिना थ्रेडिंग समस्याओं के बारे में चिंता किए बिना। ।

क्या अन्य लोग खुद को ऐसा करते हुए पाते हैं, क्योंकि मुझे वास्तव में ऐसा करना पसंद नहीं है ?? मैं व्यक्तिगत रूप से लगता है कि बोनस एक विधि को सार्वजनिक करने की समस्याओं को दूर करता है जो वास्तव में वर्ग के बाहर कोई सेवा प्रदान नहीं करता है ...

अपडेट करें

सभी के उत्तर के लिए धन्यवाद, लगता है कि लोगों की रुचि बढ़ी है। मुझे लगता है कि आम सहमति का परीक्षण सार्वजनिक एपीआई के माध्यम से होना चाहिए क्योंकि यह एकमात्र तरीका है जिसे एक वर्ग कभी भी उपयोग करेगा, और मैं इसके लिए सहमत हूं। जिन मामलों के बारे में मैंने ऊपर उल्लेख किया है, उनमें से कुछ मैं ऊपर कर रहा था असामान्य मामले थे और मुझे लगा कि ऐसा करने के लाभ इसके लायक हैं।

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


.Net में एक विशेष वर्ग होता है जिसे PrivateObject विशेष रूप से नियत किया जाता है ताकि आप किसी कक्षा के निजी तरीकों का उपयोग कर सकें।

MSDN पर या स्टैक ओवरफ़्लो पर इसके बारे में अधिक देखें

(मैं सोच रहा हूं कि किसी ने भी अब तक इसका उल्लेख नहीं किया है।)

ऐसी स्थितियां हैं, हालांकि यह पर्याप्त नहीं है, इस स्थिति में आपको प्रतिबिंब का उपयोग करना होगा।

फिर भी मैं निजी तरीकों का परीक्षण न करने की सामान्य सिफारिश का पालन करूंगा, हालांकि हमेशा की तरह अपवाद हैं।


जैसा कि बड़े पैमाने पर दूसरों की टिप्पणियों से पता चलता है, यूनिट परीक्षणों को सार्वजनिक एपीआई पर ध्यान केंद्रित करना चाहिए। हालांकि, पेशेवरों / विपक्ष और एक तरफ औचित्य, आप प्रतिबिंब का उपयोग करके एक इकाई परीक्षण में निजी तरीकों को कॉल कर सकते हैं। आपको निश्चित रूप से यह सुनिश्चित करने की आवश्यकता होगी कि आपकी JRE सुरक्षा इसकी अनुमति देती है। निजी तरीकों को कॉल करना कुछ ऐसा है जो स्प्रिंग फ्रेमवर्क इसके साथ ReflectionUtils ( makeAccessible(Method) विधि देखें )।

यहां एक छोटा उदाहरण वर्ग है जिसमें एक निजी उदाहरण विधि है।

public class A {
    private void doSomething() {
        System.out.println("Doing something private.");
    }
}

और एक उदाहरण वर्ग जो निजी उदाहरण विधि को निष्पादित करता है।

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
public class B {
    public static final void main(final String[] args) {
        try {
            Method doSomething = A.class.getDeclaredMethod("doSomething");
            A o = new A();
            //o.doSomething(); // Compile-time error!
            doSomething.setAccessible(true); // If this is not done, you get an IllegalAccessException!
            doSomething.invoke(o);
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        } catch (InvocationTargetException e) {
            e.printStackTrace();
        } catch (NoSuchMethodException e) {
            e.printStackTrace();
        } catch (SecurityException e) {
            e.printStackTrace();
        }
    }
}

बी को निष्पादित करना, प्रिंट करेगा Doing something private. यदि आपको वास्तव में इसकी आवश्यकता है, तो निजी उदाहरण विधियों तक पहुंचने के लिए यूनिट परीक्षणों में प्रतिबिंब का उपयोग किया जा सकता है।


नहीं, क्योंकि उस बिल्ली की चमड़ी उतारने के बेहतर तरीके हैं।

कुछ यूनिट टेस्ट हार्नेस वर्ग परिभाषा में मैक्रोज़ पर निर्भर करते हैं जो टेस्ट मोड में निर्मित होने पर हुक बनाने के लिए स्वचालित रूप से विस्तार करते हैं। बहुत सी शैली, लेकिन यह काम करता है।

एक आसान OO मुहावरा कुछ भी करना है जिसे आप "निजी" के बजाय "संरक्षित" का परीक्षण करना चाहते हैं। परीक्षण हार्नेस परीक्षण के तहत कक्षा से विरासत में मिलता है, और फिर सभी संरक्षित सदस्यों तक पहुंच सकता है।

या आप "दोस्त" विकल्प के लिए जाते हैं। व्यक्तिगत रूप से यह C ++ की विशेषता है मुझे कम से कम पसंद है क्योंकि यह एन्कैप्सुलेशन नियमों को तोड़ता है, लेकिन यह आवश्यक है कि C ++ कुछ सुविधाओं को कैसे लागू करता है, इसलिए हे हो।

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


मैं अक्सर की तरह एक विधि कहा जाता है कुछ जोड़ना होगा validate , verify , check एक वर्ग के लिए, आदि, इतना है कि यह एक वस्तु की आंतरिक स्थिति का परीक्षण करने के कहा जा सकता है।

कभी-कभी यह विधि एक ifdef ब्लॉक में लपेटी जाती है (मैं ज्यादातर C ++ में लिखता हूं) ताकि यह रिलीज के लिए संकलित न हो। लेकिन यह अक्सर मान्यताओं के तरीकों को प्रदान करने के लिए रिलीज़ में उपयोगी होता है जो प्रोग्राम के ऑब्जेक्ट ट्री की चीजों की जाँच करते हैं।


मैं आमतौर पर उन तरीकों को छोड़ता हूं protected और एक ही पैकेज (लेकिन किसी अन्य प्रोजेक्ट या स्रोत फ़ोल्डर में) में यूनिट टेस्ट देता हूं , जहां वे सभी संरक्षित तरीकों तक पहुंच सकते हैं क्योंकि क्लास लोडर उन्हें उसी नामस्थान के भीतर रखेगा।


अपने अद्यतन में आप कहते हैं कि सार्वजनिक एपीआई का उपयोग करके परीक्षण करना अच्छा है। यहां वास्तव में दो स्कूल हैं।

  1. ब्लैक बॉक्स परीक्षण

    ब्लैक बॉक्स स्कूल का कहना है कि कक्षा को एक ब्लैक बॉक्स माना जाना चाहिए जो कोई भी इसके अंदर कार्यान्वयन को नहीं देख सकता है। इसका परीक्षण करने का एकमात्र तरीका सार्वजनिक एपीआई के माध्यम से है - जैसे कक्षा का उपयोगकर्ता इसका उपयोग कर रहा होगा।

  2. सफेद बॉक्स परीक्षण।

    श्वेत बॉक्स स्कूल वर्ग के कार्यान्वयन के बारे में ज्ञान का उपयोग करने के लिए स्वाभाविक रूप से सोचता है और फिर यह जानने के लिए कक्षा का परीक्षण करता है कि यह काम करना चाहिए।

मैं वास्तव में चर्चा में पक्ष नहीं ले सकता। मुझे लगा कि यह जानना दिलचस्प होगा कि कक्षा (या पुस्तकालय या जो कुछ भी) का परीक्षण करने के दो अलग-अलग तरीके हैं।


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

इसके बजाय आपको "उच्च परीक्षण" करना चाहिए। निजी पद्धति को कॉल करने वाली विधि का परीक्षण करें। लेकिन आपके परीक्षणों को आपके अनुप्रयोगों की आवश्यकताओं और आपके "कार्यान्वयन निर्णयों" का परीक्षण करना चाहिए।

उदाहरण के लिए (शारीरिक छद्म कोड यहाँ);

   public int books(int a) {
     return add(a, 2);
   }
   private int add(int a, int b) {
     return a+b;
   } 

इसके बजाय "जोड़ें" का परीक्षण करने का कोई कारण नहीं है आप इसके बजाय "पुस्तकों" का परीक्षण कर सकते हैं।

कभी भी अपने परीक्षणों को आपके लिए कोड डिज़ाइन निर्णय न दें। परीक्षण करें कि आपको अपेक्षित परिणाम मिले, न कि आपको वह परिणाम कैसे मिले।


इसे पैकेज निजी बनाने के बारे में कैसे? तब आपका परीक्षण कोड इसे (और आपके पैकेज में अन्य कक्षाएं) भी देख सकता है, लेकिन यह अभी भी आपके उपयोगकर्ताओं से छिपा हुआ है।

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

एक विधि को सार्वजनिक करना बड़ी प्रतिबद्धता है। एक बार जब आप ऐसा कर लेते हैं, तो लोग इसका उपयोग करने में सक्षम होंगे, और आप उन्हें अब और नहीं बदल सकते।


एक उपयोगिता वर्ग में ढेर प्रबंधन एल्गोरिदम को विभाजित क्यों नहीं किया गया? उपयोगिता वर्ग ढेर का प्रबंधन कर सकता है और सार्वजनिक एक्सेसर्स प्रदान कर सकता है। इसके इकाई परीक्षणों को कार्यान्वयन विवरण पर ध्यान केंद्रित किया जा सकता है। एल्गोरिदमिक रूप से मुश्किल वर्गों के लिए गहन परीक्षण किनारे के मामलों को कम करने और कवरेज सुनिश्चित करने में बहुत सहायक हैं।

फिर आपका वर्तमान वर्ग किसी भी कार्यान्वयन विवरण को उजागर किए बिना उपयोगिता वर्ग को स्पष्ट रूप से सौंप सकता है। इसके परीक्षण पृष्ठांकन आवश्यकता से संबंधित होंगे जैसा कि अन्य लोगों ने सिफारिश की है।


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


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


निजी तरीके जिन्हें आप अलगाव में परीक्षण करना चाहते हैं एक संकेत है कि आपकी कक्षा में एक और "अवधारणा" दफन है। उस "अवधारणा" को अपनी कक्षा में निकालें और इसे एक अलग "इकाई" के रूप में परखें।

इस वीडियो पर एक नज़र डालें विषय पर एक बहुत ही दिलचस्प के लिए।


निजी तरीकों को आमतौर पर "सहायक" विधियों के रूप में उपयोग किया जाता है। इसलिए वे केवल मूल मूल्यों को वापस करते हैं और कभी भी वस्तुओं के विशिष्ट उदाहरणों पर काम नहीं करते हैं।

यदि आप उनका परीक्षण करना चाहते हैं तो आपके पास कुछ विकल्प हैं।

  • प्रतिबिंब का उपयोग करें
  • तरीकों पैकेज का उपयोग दे

वैकल्पिक रूप से आप एक सहायक विधि के रूप में एक सार्वजनिक विधि के रूप में एक नया वर्ग बना सकते हैं यदि यह एक नए वर्ग के लिए एक अच्छा उम्मीदवार है।

इस पर यहाँ बहुत अच्छा लेख है


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

"निजी" विधियों का परीक्षण करने का सामान्य तरीका हर वर्ग को अपना इंटरफ़ेस देना है, और "निजी" तरीकों को public , लेकिन उन्हें इंटरफ़ेस में शामिल नहीं करना है। इस तरह, उन्हें अभी भी परीक्षण किया जा सकता है, लेकिन वे इंटरफ़ेस को ब्लोट नहीं करते हैं।

हां, यह फ़ाइल- और वर्ग-ब्लोट में परिणाम देगा।

हां, यह public और private विशेषकों को निरर्थक बना देता है।

हां, यह गधे का दर्द है।

यह, दुर्भाग्य से, हम कोड परीक्षण करने योग्य कई बलिदानों में से एक है । शायद एक भविष्य की भाषा (या सी # / जावा का एक भविष्य का संस्करण) में क्लास- और मॉड्यूल-परीक्षण क्षमता को और अधिक सुविधाजनक बनाने की विशेषताएं होंगी; लेकिन इस बीच, हमें इन हुप्स के माध्यम से कूदना होगा।

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


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

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

यह पाठ्यक्रम केवल आपके प्रश्न के C # / .NET भाग पर लागू होता है


मैं कहूंगा कि यह मेरे लिए एक बुरा विचार है कि मुझे यकीन नहीं है कि आपको कोई लाभ मिलता है और संभावित रूप से समस्याएं नीचे आती हैं। यदि आप कॉल के अनुबंध को बदल रहे हैं, तो बस एक निजी पद्धति का परीक्षण करने के लिए, आप कक्षा का परीक्षण नहीं कर रहे हैं कि इसका उपयोग कैसे किया जाएगा, लेकिन एक कृत्रिम परिदृश्य का निर्माण करना, जिसे आपने कभी नहीं होने दिया।

इसके अलावा, विधि को सार्वजनिक घोषित करके, क्या कहना है कि छह महीने के समय में (यह भूल जाने के बाद कि विधि को सार्वजनिक करने का एकमात्र कारण परीक्षण के लिए है) कि आप (या यदि आपने परियोजना को सौंप दिया है) तो कोई पूरी तरह से जीता है 'इसका उपयोग न करें, संभावित अनपेक्षित परिणामों और / या रखरखाव दुःस्वप्न के कारण।


यदि आप C # का उपयोग कर रहे हैं, तो आप विधि को आंतरिक बना सकते हैं। इस तरह से आप सार्वजनिक API को प्रदूषित नहीं करते हैं।

फिर dll में विशेषता जोड़ें

[असेंबली: इंटरनैल्सविजेल्टो ("MyTestAssembly")]

अब आपके MyTestAssembly प्रोजेक्ट में सभी विधियाँ दिखाई दे रही हैं। शायद सही नहीं है, लेकिन बेहतर है तो इसे जांचने के लिए निजी पद्धति को सार्वजनिक करना।


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


व्यक्तिगत रूप से, मैं सार्वजनिक API का उपयोग करके इकाई परीक्षण करना चाहूंगा और मैं निश्चित रूप से निजी पद्धति को कभी भी सार्वजनिक नहीं करूंगा ताकि यह परीक्षण करना आसान हो सके।

यदि आप वास्तव में अलगाव में निजी विधि का परीक्षण करना चाहते हैं, तो जावा में आप Easymock / Powermock का उपयोग कर सकते हैं Easymock आप ऐसा कर सकें।

आपको इसके बारे में व्यावहारिक होना चाहिए और आपको उन कारणों के बारे में भी पता होना चाहिए जिनकी वजह से परीक्षण करना मुश्किल है।

' परीक्षण सुनें ' - यदि परीक्षण करना कठिन है, तो क्या यह आपको अपने डिजाइन के बारे में कुछ बता रहा है? क्या आप इस बात के लिए रिफ्लेक्टर कर सकते हैं कि इस विधि के लिए एक परीक्षण तुच्छ होगा और आसानी से सार्वजनिक एपीआई के माध्यम से परीक्षण करके कवर किया जाएगा?

यहां माइकल फेदर को ' वर्किंग इफेक्टिवली विद लिगेसी कोड ' में क्या कहना है

"बहुत से लोग इस समस्या के आसपास पाने के लिए ओटी का पता लगाने में बहुत समय बिताते हैं ... असली जवाब यह है कि यदि आपके पास एक निजी विधि का परीक्षण करने का आग्रह है, तो विधि निजी नहीं होनी चाहिए; यदि विधि को सार्वजनिक किया जाए; आपको परेशान करता है, संभावना है, यह इसलिए है क्योंकि यह एक अलग पुनरावृत्ति का हिस्सा है; यह किसी अन्य वर्ग पर होना चाहिए। " [एम। पंख द्वारा लिगेसी कोड (2005) के साथ प्रभावी ढंग से काम करना ]








unit-testing