परीक्षण प्रेरित विकास: फाइल सिस्टम संचालन का परीक्षण करने का एक अच्छा / स्वीकृत तरीका?

14

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

testing unit-testing file-handling

— Kirbinator
स्रोत

13

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

— डॉक्टर ब्राउन
स्रोत

टीडीडी परीक्षण के तहत इकाई के कार्यान्वयन का मजाक उड़ाने की सिफारिश नहीं करता है। देखें (उदा) solnic.eu/2014/05/22/mocking-and-ruby.html

— soru

1

@ सोरू: यह वह नहीं है जो यह उत्तर सुझाता है। यह पहले इंटरफेस बनाने की सलाह देता है, फिर इंटरफ़ेस का मज़ाक उड़ाता है । तो आप व्यापार तर्क का परीक्षण करते हैं, लेकिन फाइलसिस्टम इंटरफ़ेस का नहीं।

— सलेस्के

5

लेकिन ऐसा लगता है कि व्यापार तर्क फ़ाइलों और निर्देशिकाओं के संदर्भ में परिभाषित किया गया है। तो फ़ाइल सिस्टम API को कॉल करने वाला सामान वह सामान है जिसे परीक्षण की आवश्यकता है। किसी भी संबंधित गैर-फ़ाइल व्यावसायिक तर्क का परीक्षण करने के लिए मॉकिंग की आवश्यकता नहीं है; बस इसे परखो।

— सोरू

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

— जूल्स

2

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

— एंड्रयू सविनाख

11

"परीक्षण" फाइल सिस्टम होने के कारण गलत है?

एक टेम्प्लेट फ़ोल्डर / निर्देशिका संरचना बनाएं जिसमें आपके कार्यों का परीक्षण करने के लिए पर्याप्त सामग्री हो।

अपनी इकाई परीक्षण की स्थापना के दौरान इस प्रारंभिक संरचना की प्रतिलिपि बनाएँ (क्या आप टेम्पलेट को ज़िप करेंगे और अपने परीक्षण क्षेत्र में अनज़िप कर सकते हैं)। अपने परीक्षण चलाएं। आंसू के दौरान पूरी चीज को हटा दें।

मॉकिंग के साथ समस्या सबसे पहले फाइल सिस्टम, OSes और डेटाबेस की है जो आपकी परियोजना से संबंधित हैं जो वास्तव में बाहरी संसाधनों के रूप में योग्य नहीं हैं और दूसरी बात यह है कि निम्न स्तर की सिस्टम कॉल का मजाक उड़ाने में समय लगता है और त्रुटि का खतरा होता है।

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

5

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

— डॉक्टर ब्राउन

1

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

— फ्रैंक हिलमैन

2

@ डॉक ब्राउन - मुझे लगता है कि वह यह करना चाहता है कि वह डायर हटाए, और बदले हुए प्रकार के ऑपरेशनों को करना चाहता है, जिनमें किनारे के सभी मामले हैं जो नकली होना दर्दनाक होगा। इसके अलावा आधुनिक हार्डवेयर पर एक निर्देशिका में कुछ छोटी फ़ाइलों को खोलना केवल जावा वर्ग को लोड करने की तुलना में थोड़ा धीमा है - इसके बाद के सभी IO।

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

मैं जितना अधिक टेस्ट फाइल सिस्टम के बारे में सोचता हूं, मुझे उतना ही अच्छा लगता है।

— फ्रैंक हिलमैन

3

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

इसलिए टीडीडी दृष्टिकोण को पहले एकीकरण परीक्षण लिखना है (टीडीडी, सख्ती से बोलना, 'यूनिट टेस्ट' और 'एकीकरण परीक्षण' की अलग-अलग अवधारणाएं नहीं हैं; वे सिर्फ परीक्षण हैं)। काफी संभावना है कि पर्याप्त होगा; इसलिए काम किया, बंद करो, घर जाओ ।

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

किसी भी मामले में आप जो कोड लिख रहे हैं उसके मौलिक मूल को ले लेंगे और परीक्षण लिखने के लिए इसे 'मॉक' कर देंगे जो परीक्षण के तहत यूनिट पास होगी या नहीं, गलत है।

— soru
स्रोत

इस उत्तर ने वास्तव में इसे मेरे लिए परिप्रेक्ष्य में रख दिया - 'unit test' and 'integration test'; they are just tests.मुझे लगता है कि वास्तविक रूप से, यह मेरे मामले का सबसे अच्छा समाधान होने जा रहा है - मुझे वास्तव में फ़ाइल सिस्टम लाइब्रेरी का परीक्षण करने की आवश्यकता है जिसका उपयोग मैं किनारे के मामलों के लिए कर रहा हूं, और आवेदन का जवाब कैसे देना चाहिए उन। यदि मैं एक अलग फाइल सिस्टम लाइब्रेरी में स्विच करता हूं, तो मैं नई लाइब्रेरी के साथ काम करने के लिए मोक्स / टेस्ट कोड का एक गुच्छा फिर से लिखना नहीं चाहता, लेकिन एक परीक्षण फ़ोल्डर संरचना और एकीकरण परीक्षण होने से यह बहुत सरल हो जाएगा।

— तेहदॉर्फ

2

मैं आपके प्रश्न को "क्लास सिस्टम का परीक्षण करने के लिए एक अच्छा / स्वीकृत तरीका मानता हूं जो फ़ाइल सिस्टम ऑपरेशन पर निर्भर करता है"। मैं यह नहीं मानता कि आप अपने ओएस की फाइलसिस्टम का परीक्षण करना चाहते हैं।

अपने फाइलसिस्टम के संचालन के लिए इंटरफेस और उन्हें "मॉक आउट" करने के प्रयास को जारी रखने के लिए @ डॉक ब्राउन के उत्तर के रूप में संभव के रूप में छोटे रूप में सुझाव दिया गया कि जावा बाइनरी स्ट्रीम या टेक्स्ट रीडर (या c # में समतुल्य) का उपयोग करना एक अच्छा विचार है। आप जिस भाषा का उपयोग कर रहे हैं, उसकी प्रोग्रामिंग भाषा) फाइल के साथ फाइल का उपयोग करने के बजाय सीधे आप में tdd- विकसित वर्ग।

उदाहरण:

जावा का उपयोग करके मैंने एक वर्ग CsvReader लागू किया है

public class CsvReader {
    private Reader reader;

    public CsvReader(Reader reader) {
        this.reader = reader;
    }
}

परीक्षण के लिए मैंने इस तरह से मेमोरी डेटा का उपयोग किया

String contentOfCsv = "TestColumn1;TestColumn2\n"+
    "value1;value2\n";

CsvReader sut = new CsvReader(java.io.StringReader(contentOfCsv));

या संसाधनों में टेस्टडेटा को लागू करना

CsvReader sut = new CsvReader(getClass().getResourceAsStream("/data.csv"));

उत्पादन में मैं फ़ाइल सिस्टम का उपयोग करता हूं

CsvReader sut = new CsvReader(new BufferedReader( new FileReader( "/import/Prices.csv" ) ));

इस तरह मेरा CsvReader फाइलसिस्टम पर निर्भर नहीं करता है, लेकिन एब्सट्रैक्शन "रीडर" पर है जहां फाइलसिस्टम के लिए कार्यान्वयन है।

— के 3 बी
स्रोत

2

यहाँ एकमात्र समस्या यह है कि ओपी फाइल ऑपरेशंस की बात नहीं कर रहा था, लेकिन फाइल सिस्टम ऑपरेशंस और मेटा डेटा ऑपरेशंस - मुझे लगता है कि उसका मतलब था किसी डायरेक्टरी की सभी फाइलों को सूचीबद्ध करना, सभी पिक्चर फाइलों में कुछ EXIF जानकारी अपडेट करना आदि

— Doc Brown

यह सही है।

— किरिबनेटर

1

आप IDirectoryLister बना सकते हैं जिसमें एक विधि है स्ट्रिंग [] सूची (स्ट्रिंग निर्देशिका); उसके बाद FakeDirectoryLister नई स्ट्रिंग [] {"।", "..", "foo.bat", "bar.exe"} वापस करके उस पद्धति को लागू कर सकता है;

— एंडर्स लिंडेन

0

फ़ाइल सिस्टम ऑपरेशन के लिए एक आवरण बनाएँ। परीक्षणों में, एक नकली में गुजरता है जो आवरण के समान इंटरफ़ेस को लागू करता है। उत्पादन में, आवरण में पास।

— jhewlett
स्रोत