फ़ाइल सिस्टम निर्भरता के साथ यूनिट परीक्षण कोड

138

मैं एक घटक लिख रहा हूं, जिसे एक जिप फाइल दी गई है:

फ़ाइल खोलना।
अनज़ैप्ड फ़ाइलों के बीच एक विशिष्ट डीएल का पता लगाएं।
प्रतिबिंब के माध्यम से उस dll को लोड करें और उस पर एक विधि लागू करें।

मैं इस घटक का परीक्षण करना चाहूंगा।

मैं कोड लिखने के लिए ललचा रहा हूँ जो सीधे फाइल सिस्टम के साथ काम करता है:

void DoIt()
{
   Zip.Unzip(theZipFile, "C:\\foo\\Unzipped");
   System.IO.File myDll = File.Open("C:\\foo\\Unzipped\\SuperSecret.bar");
   myDll.InvokeSomeSpecialMethod();
}

लेकिन लोग अक्सर कहते हैं, "इकाई परीक्षण न लिखें जो फ़ाइल सिस्टम, डेटाबेस, नेटवर्क, आदि पर भरोसा करते हैं"

अगर मुझे इसे यूनिट-टेस्ट फ्रेंडली तरीके से लिखना था, तो मुझे लगता है कि यह इस तरह दिखेगा:

void DoIt(IZipper zipper, IFileSystem fileSystem, IDllRunner runner)
{
   string path = zipper.Unzip(theZipFile);
   IFakeFile file = fileSystem.Open(path);
   runner.Run(file);
}

वाह! अब यह परीक्षण करने योग्य है; मैं DoIt विधि के लिए परीक्षण युगल (नकली) में फ़ीड कर सकते हैं। लेकिन किस कीमत पर? मुझे अब इस परीक्षण योग्य बनाने के लिए 3 नए इंटरफेस परिभाषित करने होंगे। और क्या, वास्तव में, क्या मैं परीक्षण कर रहा हूं? मैं परीक्षण कर रहा हूं कि मेरा DoIt फ़ंक्शन ठीक से अपनी निर्भरता के साथ सहभागिता करता है। यह परीक्षण नहीं करता है कि ज़िप फ़ाइल ठीक से अनज़िप की गई थी, आदि।

ऐसा महसूस नहीं होता है कि मैं कार्यक्षमता का परीक्षण कर रहा हूं। ऐसा लगता है कि मैं सिर्फ कक्षा की बातचीत का परीक्षण कर रहा हूं।

मेरा सवाल यह है : फ़ाइल सिस्टम पर निर्भर किसी चीज़ का परीक्षण करने का उचित तरीका क्या है?

मैं संपादित कर रहा हूँ .NET का उपयोग कर रहा हूं, लेकिन अवधारणा जावा या देशी कोड भी लागू कर सकती है।

unit-testing dependency-injection dependencies

— जुदा गेब्रियल हिमंगो
स्रोत

8

दोस्तों का कहना है कि एक यूनिट टेस्ट में फाइल सिस्टम को न लिखें क्योंकि अगर आपको फाइल सिस्टम में लिखने के लिए लुभाया जाता है तो आप समझ नहीं रहे हैं कि यूनिट टेस्ट क्या होता है। एक इकाई परीक्षण आमतौर पर एक एकल वास्तविक वस्तु (परीक्षण के तहत इकाई) के साथ बातचीत करता है और अन्य सभी निर्भरताएं मजाक में और पारित हो जाती हैं। परीक्षण वर्ग में तब परीक्षण विधियां शामिल होती हैं जो ऑब्जेक्ट के तरीकों के माध्यम से तार्किक पथों को मान्य करती हैं और केवल तार्किक तरीके बताती हैं। परीक्षण के तहत इकाई।

— क्रिस्टोफर पेरी

1

आपकी स्थिति में इकाई परीक्षण की आवश्यकता वाला एकमात्र भाग वह होगा myDll.InvokeSomeSpecialMethod();जहाँ आप जाँचेंगे कि यह सफलता और असफल दोनों स्थितियों में सही ढंग से काम करता है इसलिए मैं इकाई परीक्षण नहीं करूँगा, DoItलेकिन DllRunner.Runकहा कि संयुक्त जांच में यूएनआईटी परीक्षण का दुरुपयोग करते हुए पूरी प्रक्रिया होगी। एक स्वीकार्य दुरुपयोग और जैसा कि यह एक एकीकरण परीक्षण होगा एक इकाई की जांच करने वाली एक इकाई है जो सामान्य इकाई परीक्षण नियमों को कड़ाई से लागू करने की आवश्यकता नहीं है

— माइक टीटी

47

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

chdir()अपने परीक्षण को चलाने से पहले एक अस्थायी निर्देशिका में और chdir()बाद में वापस आना भी एक अच्छा विचार होगा ।

— एडम रोसेनफील्ड
स्रोत

27

+1, हालांकि ध्यान दें कि chdir()यह प्रक्रिया-व्यापी है ताकि आप अपने परीक्षणों को समानांतर में चलाने की क्षमता को तोड़ सकें, यदि आपका परीक्षण ढांचा या भविष्य का संस्करण इसका समर्थन करता है।

69

वाह! अब यह परीक्षण करने योग्य है; मैं DoIt विधि के लिए परीक्षण युगल (नकली) में फ़ीड कर सकते हैं। लेकिन किस कीमत पर? मुझे अब इस परीक्षण योग्य बनाने के लिए 3 नए इंटरफेस परिभाषित करने होंगे। और क्या, वास्तव में, क्या मैं परीक्षण कर रहा हूं? मैं परीक्षण कर रहा हूं कि मेरा DoIt फ़ंक्शन ठीक से अपनी निर्भरता के साथ सहभागिता करता है। यह परीक्षण नहीं करता है कि ज़िप फ़ाइल ठीक से अनज़िप की गई थी, आदि।

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

— बढ़ रही है
स्रोत

12

परीक्षण योग्य DoItफ़ंक्शन जैसा कि कहा गया है, परीक्षण की भी आवश्यकता नहीं है। जैसा कि प्रश्नकर्ता ने ठीक ही कहा है कि परीक्षण करने के लिए कोई महत्व नहीं बचा है। अब यह कार्यान्वयन है IZipper, IFileSystemऔर IDllRunnerजिसे परीक्षण की आवश्यकता है, लेकिन वे बहुत ही चीजें हैं जो परीक्षण के लिए नकली हैं!

— इयान गोल्डी

56

आपका प्रश्न डेवलपर्स के लिए परीक्षण के सबसे कठिन भागों में से एक को उजागर करता है:

"मैं क्या परीक्षण करूं?"

आपका उदाहरण बहुत दिलचस्प नहीं है क्योंकि यह सिर्फ कुछ एपीआई कॉल को एक साथ glues करता है इसलिए यदि आप इसके लिए एक इकाई परीक्षण लिखने के लिए थे तो आप बस उस तरीके को कहते हुए समाप्त कर देंगे। इस तरह के परीक्षण कसौटी पर आपके कार्यान्वयन के विवरणों को कसौटी पर कसते हैं। यह बुरा है क्योंकि अब आपको हर बार अपनी पद्धति के कार्यान्वयन विवरण को बदलने के लिए परीक्षण को बदलना होगा क्योंकि कार्यान्वयन विवरण बदलने से आपका परीक्षण टूट जाता है!

खराब परीक्षण होना वास्तव में कोई परीक्षण नहीं होने से भी बदतर है।

आपके उदाहरण में:

void DoIt(IZipper zipper, IFileSystem fileSystem, IDllRunner runner)
{
   string path = zipper.Unzip(theZipFile);
   IFakeFile file = fileSystem.Open(path);
   runner.Run(file);
}

जब आप मोक्स में पास हो सकते हैं, तो परीक्षण करने की विधि में कोई तर्क नहीं है। यदि आप इसके लिए एक इकाई परीक्षण का प्रयास कर रहे थे तो यह कुछ इस तरह दिखाई दे सकता है:

// Assuming that zipper, fileSystem, and runner are mocks
void testDoIt()
{
  // mock behavior of the mock objects
  when(zipper.Unzip(any(File.class)).thenReturn("some path");
  when(fileSystem.Open("some path")).thenReturn(mock(IFakeFile.class));

  // run the test
  someObject.DoIt(zipper, fileSystem, runner);

  // verify things were called
  verify(zipper).Unzip(any(File.class));
  verify(fileSystem).Open("some path"));
  verify(runner).Run(file);
}

बधाई हो, आपने मूल रूप से अपनी DoIt()पद्धति के कार्यान्वयन विवरणों को परीक्षण में कॉपी-पेस्ट किया है । खुश बनाए रखना।

जब आप परीक्षण लिखते हैं तो आप WHAT का परीक्षण करना चाहते हैं न कि HOW का । अधिक के लिए ब्लैक बॉक्स परीक्षण देखें ।

क्या आपके विधि का नाम है (या कम से कम यह होना चाहिए)। कैसे सभी छोटी कार्यान्वयन विवरण है कि आपके विधि के अंदर रहते हैं। अच्छे परीक्षण आपको WHAT को तोड़ने के बिना HOW को स्वैप करने की अनुमति कैसे देते हैं ।

इस तरह से सोचें, खुद से पूछें:

"यदि मैं इस पद्धति के कार्यान्वयन विवरण को बदल देता हूं (सार्वजनिक अनुबंध में बदलाव किए बिना) तो क्या यह मेरे परीक्षण को तोड़ देगा?"

यदि उत्तर हाँ है, तो आप HOW का परीक्षण कर रहे हैं न कि WHAT का ।

फ़ाइल सिस्टम निर्भरता के साथ परीक्षण कोड के बारे में आपके विशिष्ट प्रश्न का उत्तर देने के लिए, मान लें कि आपके पास फ़ाइल के साथ कुछ और दिलचस्प चल रहा है और आप किसी फ़ाइल के Base64 एन्कोडेड सामग्री को सहेजना चाहते थे byte[]। आप यह जांचने के लिए स्ट्रीम का उपयोग कर सकते हैं कि आपका कोड सही तरीके से यह जांचे बिना करता है कि यह कैसे करता है। एक उदाहरण कुछ इस तरह हो सकता है (जावा में):

interface StreamFactory {
    OutputStream outStream();
    InputStream inStream();
}

class Base64FileWriter {
    public void write(byte[] contents, StreamFactory streamFactory) {
        OutputStream outputStream = streamFactory.outStream();
        outputStream.write(Base64.encodeBase64(contents));
    }
}

@Test
public void save_shouldBase64EncodeContents() {
    OutputStream outputStream = new ByteArrayOutputStream();
    StreamFactory streamFactory = mock(StreamFactory.class);
    when(streamFactory.outStream()).thenReturn(outputStream);

    // Run the method under test
    Base64FileWriter fileWriter = new Base64FileWriter();
    fileWriter.write("Man".getBytes(), streamFactory);

    // Assert we saved the base64 encoded contents
    assertThat(outputStream.toString()).isEqualTo("TWFu");
}

परीक्षण ByteArrayOutputStreamआवेदन में एक का उपयोग करता है (निर्भरता इंजेक्शन का उपयोग करके) वास्तविक स्ट्रीमफैक्ट्री (शायद फाइलस्ट्रीमफैक्टरी कहा जाता है) FileOutputStreamसे वापस आ outputStream()जाएगा और एक को लिख देगा File।

writeयहां की विधि के बारे में जो रोचक था वह यह है कि यह बेस 64 इनकोडेड कंटेंट लिख रहा था, इसलिए हमने इसके लिए परीक्षण किया। आपकी DoIt()विधि के लिए, यह एक एकीकरण परीक्षण के साथ अधिक उचित रूप से परीक्षण किया जाएगा ।

— क्रिस्टोफर पेरी
स्रोत

1

मुझे यकीन नहीं है कि मैं यहां आपके संदेश से सहमत हूं। क्या आप यह कह रहे हैं कि इस तरह की विधि को जांचने की कोई आवश्यकता नहीं है? तो आप मूल रूप से कह रहे हैं कि टीडीडी खराब है? जैसे कि यदि आप TDD करते हैं तो आप पहले टेस्ट लिखे बिना इस विधि को नहीं लिख सकते हैं। या आप एक कूबड़ पर भरोसा करने के लिए हैं कि आपकी विधि को परीक्षण की आवश्यकता नहीं होगी? सभी इकाई परीक्षण ढाँचों में "सत्यापन" सुविधा शामिल होने का कारण यह है कि इसका उपयोग करना ठीक है। "यह बुरा है क्योंकि अब आपको हर बार परीक्षण को बदलना होगा जब आप अपने तरीके के कार्यान्वयन के विवरण को बदलते हैं" ... इकाई परीक्षण की दुनिया में आपका स्वागत है।

— रॉनी

2

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

— क्रिस्टोफर पेरी

@ रॉनी आँख बंद करके यूनिट टेस्टिंग में मददगार नहीं है। व्यापक रूप से भिन्न प्रकृति की परियोजनाएं हैं, और यूनिट परीक्षण उन सभी में प्रभावी नहीं है। एक उदाहरण के रूप में, मैं एक ऐसी परियोजना पर काम कर रहा हूं जिसमें 95% कोड साइड-इफेक्ट्स के बारे में है (ध्यान दें, यह साइड-इफेक्ट-भारी प्रकृति आवश्यकता के अनुसार है , यह आवश्यक जटिलता है, आकस्मिक नहीं , क्योंकि यह डेटा इकट्ठा करता है। राज्य स्रोतों की एक विस्तृत विविधता और इसे बहुत कम हेरफेर के साथ प्रस्तुत करता है, इसलिए शायद ही कोई शुद्ध तर्क है)। इकाई परीक्षण यहां प्रभावी नहीं है, एकीकरण परीक्षण है।

— विक्की चिजवानी

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

— क्रिस्टोफर पेरी

24

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

इस पर मेरी राय यह है कि आपकी इकाई परीक्षण उतना ही करेंगे जितना कि वे 100% कवरेज नहीं कर सकते हैं। वास्तव में, यह केवल 10% हो सकता है। मुद्दा यह है, आपकी इकाई परीक्षण तेज होना चाहिए और कोई बाहरी निर्भरता नहीं होनी चाहिए। वे इस तरह के मामलों का परीक्षण कर सकते हैं "जब आप इस पैरामीटर के लिए अशक्त में गुजरते हैं तो यह विधि एक ArgumentNullException फेंकता है"।

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

कोड कवरेज को मापते समय, मैं इकाई और एकीकरण परीक्षण दोनों को मापता हूं।

— केंट बूगार्ट
स्रोत

5

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

— यहूदा गैब्रियल हिमंगो

6

यह उत्तर पथभ्रष्ट है। यूनिट टेस्टिंग फ्रॉस्टिंग की तरह नहीं है, यह चीनी की तरह अधिक है। इसे केक में पकाया जाता है। यह आपके कोड को लिखने का एक हिस्सा है ... एक डिजाइन गतिविधि। इसलिए, आप अपने कोड को कभी भी "प्रदूषण" नहीं करते हैं जो "परीक्षण की सुविधा" देगा क्योंकि परीक्षण वह है जो आपको अपना कोड लिखने की सुविधा देता है। एक परीक्षण लिखने के लिए 99% समय कठिन होता है क्योंकि डेवलपर ने परीक्षण से पहले कोड लिखा था, और बुरी तरह से अनपेक्षित कोड

— क्रिस्टोफर पेरी

1

@ क्रिस्टोफर: अपने सादृश्य का विस्तार करने के लिए, मैं नहीं चाहता कि मेरा केक एक वेनिला टुकड़ा जैसा हो, ताकि मैं चीनी का उपयोग कर सकूं। सब मैं वकालत कर रहा हूँ व्यावहारिकता है।

— केंट बोगार्ट

1

@ क्रिस्टोफर: आपके जैव यह सब कहते हैं: "मैं एक TDD जोएलोट हूं"। दूसरी ओर, मैं व्यावहारिक हूं। मैं टीडीडी करता हूं जहां यह फिट बैठता है और यह नहीं कि यह कहां नहीं है - मेरे जवाब में कुछ भी नहीं बताता है कि मैं टीडीडी नहीं करता हूं, हालांकि आपको लगता है कि यह करता है। और यह TDD है या नहीं, मैं परीक्षण की सुविधा के लिए बड़ी मात्रा में जटिलता का परिचय नहीं दूंगा।

— केंट बूगार्ट

3

@ChristopherPerry क्या आप बता सकते हैं कि ओपी के मूल मुद्दे को टीडीडी तरीके से कैसे हल किया जाए? मैं हर समय इसमें भागता हूं; मुझे एक फ़ंक्शन लिखने की आवश्यकता है जिसका एकमात्र उद्देश्य इस प्रश्न में एक बाहरी निर्भरता के साथ एक क्रिया करना है। यहाँ तक कि लिखने-में-परीक्षण-प्रथम परिदृश्य में भी, वह परीक्षण भी क्या होगा?

— डैक्स फोहल

8

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

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

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

— जे.सी.।
स्रोत

वे कितनी बार चलते हैं, इसकी थोड़ी चिंता है; हम एक निरंतर एकीकरण सर्वर का उपयोग करते हैं जो स्वचालित रूप से हमारे लिए उन्हें चलाता है। हम वास्तव में परवाह नहीं करते हैं कि उन्हें कितना समय लगता है। यदि "कितनी देर तक चलना है" तो चिंता की बात नहीं है, क्या यूनिट और एकीकरण परीक्षणों के बीच अंतर करने का कोई कारण है?

— जुडाह गेब्रियल हिमांगो

4

ज़रुरी नहीं। लेकिन अगर डेवलपर्स स्थानीय स्तर पर सभी यूनिट परीक्षणों को जल्दी से चलाना चाहते हैं तो ऐसा करने का एक आसान तरीका है।

— जे.सी.

6

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

— nsayer
स्रोत

ठीक है, ताकि धारा के इंजेक्शन के लिए अनुमति देता है। निर्भरता इंजेक्शन / आईओसी। कैसे फ़ाइलों में धारा unzipping के भाग के बारे में, उन फ़ाइलों के बीच एक dll लोड हो रहा है, और उस dll में एक विधि को बुला रहा है?

— जुडाह गेब्रियल हिमांगो

3

यह एक एकीकरण परीक्षण से अधिक प्रतीत होता है क्योंकि आप एक विशिष्ट विवरण (फाइल सिस्टम) पर निर्भर होते हैं जो सिद्धांत में बदल सकते हैं।

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

— नल टोटी
स्रोत

2

यह मानते हुए कि "फ़ाइल सिस्टम इंटरैक्शन" को स्वयं फ्रेमवर्क में अच्छी तरह से जांचा जाता है, धाराओं के साथ काम करने के लिए अपना तरीका बनाएं और इसका परीक्षण करें। एक फाइलस्ट्रीम खोलना और इसे विधि में पास करना आपके परीक्षणों से बाहर रह सकता है, क्योंकि फाइलस्ट्रीम.ऑपन को फ्रेमवर्क रचनाकारों द्वारा अच्छी तरह से परखा जाता है।

— सनी मिलेंव
स्रोत

आपके और nsayer के पास अनिवार्य रूप से एक ही सुझाव है: धाराओं के साथ मेरा कोड काम करें। कैसे dll फ़ाइलों में स्ट्रीम सामग्री को खोलना, उस dll को खोलने और उसमें किसी फ़ंक्शन को कॉल करने के बारे में कैसे? आप वहां क्या करेंगे?

— यहूदा गैब्रियल हिमंगो

3

@JudahHimango। जरूरी नहीं कि वे हिस्से परीक्षण योग्य हों। आप हर चीज का परीक्षण नहीं कर सकते। संयुक्त राष्ट्र के परीक्षण योग्य घटकों को अपने स्वयं के कार्यात्मक ब्लॉकों में सार करें, और मान लें कि वे काम करेंगे। जब आप इस ब्लॉक के काम करने के तरीके के साथ एक बग में आते हैं, तो इसके लिए एक परीक्षण तैयार करें, और वॉइला। इकाई परीक्षण का मतलब यह नहीं है कि आपको हर चीज का परीक्षण करना होगा। कुछ परिदृश्यों में 100% कोड कवरेज अवास्तविक है।

— ज़ोरन पावलोविक

1

आपको क्लास इंटरैक्शन और फ़ंक्शन कॉलिंग का परीक्षण नहीं करना चाहिए। इसके बजाय आपको एकीकरण परीक्षण पर विचार करना चाहिए। आवश्यक परिणाम का परीक्षण करें और फ़ाइल लोडिंग ऑपरेशन नहीं।

— दारु हेल्पर
स्रोत

1

इकाई परीक्षण के लिए मैं आपको सुझाव दूंगा कि आप अपनी परियोजना में परीक्षण फ़ाइल (EAR फ़ाइल या समतुल्य) शामिल करें, फिर इकाई परीक्षणों में एक सापेक्ष पथ का उपयोग करें "../testdata/testfile"।

जब तक आपकी परियोजना सही ढंग से निर्यात / आयात की जाती है, तब तक आपकी इकाई परीक्षण से काम करना चाहिए।

— जेम्स एंडरसन
स्रोत

0

जैसा कि दूसरों ने कहा है, पहला एकीकरण परीक्षण के रूप में ठीक है। दूसरा परीक्षण केवल वही कार्य करता है जो वास्तव में करना चाहिए, जो कि एक इकाई परीक्षण है।

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

— डेविड साइक्स
स्रोत