मैं एक फ़ाइल रीडर का परीक्षण कैसे करूं?


19

मैं कुछ फ़ाइल स्वरूपों के साथ एक परियोजना पर काम कर रहा हूँ। कुछ प्रारूप .xsds द्वारा निर्दिष्ट किए गए हैं, अन्य अपने संबंधित वेबसाइटों पर दस्तावेज़ीकरण द्वारा, और कुछ कस्टम-हाउस प्रारूप हैं जिनमें कोई दस्तावेज़ नहीं है। Mwahahahaha।

समस्या क्या है?

मैं अपने फ़ाइल पाठकों का परीक्षण करना चाहूंगा, लेकिन मुझे पूरी तरह से यकीन नहीं है कि यह कैसे करना है। आवेदन का प्रवाह इस प्रकार है:

file.___  ===> read by FileReader.java ===> which creates a Model object

FileReaderइंटरफ़ेस कहाँ है

public interface FileReader {
    public Model read(String filename);
}

Modelविशेषताओं है कि जब फाइल पढ़ने के लिए है भर जाती है की एक संख्या है। यह कुछ ऐसा दिखता है

public class Model {
    List<String> as;
    List<String> bs;
    boolean isAPain = true;
    // ...
}

मैंने क्या कोशिश की है?

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

हालांकि इसमें कुछ समस्याएं हैं:

  • यह उत्पन्न करने वाली फ़ाइलें वास्तविक फ़ाइलों की तरह नहीं दिखती हैं। जनरेटर किसी भी तरह से संदर्भ से अवगत नहीं है।
  • यह पहचानना मुश्किल है कि क्या जेनरेटर किनारे के मामलों के लिए उत्पन्न हुआ है क्योंकि मैं मैन्युअल रूप से चर सेट कर रहा हूं। एक दर्जन सैंपल फाइल बनाने की तुलना में यह विधि मेरे लिए बेहतर नहीं है।

क्या ऐसा करने के कोई बेहतर तरीके हैं?

संपादित करें: क्योंकि मैं वास्तव में क्या मतलब है एकीकरण इकाई बदल गया है।

EDIT2: यहां मेरे द्वारा उल्लेखित किनारे मामलों का एक उदाहरण है।

प्रत्येक फ़ाइल वर्टिकल और किनारों से बने ग्राफ़ का प्रतिनिधित्व करती है। ये कोने और किनारों को अलग-अलग तरीकों से जोड़ा जा सकता है, इसलिए:

v1 -- e1 --> v2 <-- e2 -- v3

से अलग है

v1 -- e1 --> v2 -- e2 --> v3

उस में किनारों की दिशा मायने रखती है। मुझे यकीन नहीं है कि अगर यह सवाल के दायरे में है, लेकिन यह मुश्किल है कि सभी धारियों के मामले उठें, जब मैं मैन्युअल रूप से कोने की संख्या, किनारों की संख्या निर्धारित करता हूं, और बस यादृच्छिक रूप से कनेक्शन उत्पन्न करता हूं।


1
डेटा-चालित परीक्षण दिमाग में आता है। क्या आप किनारे के मामलों के ठोस उदाहरण दे सकते हैं (किनारे के मामलों के आधार पर जिन्हें वास्तविक FileReaderकार्यान्वयन में संभवतः ट्रिगर किया जा सकता है)। उदाहरण: छवि फ़ाइल स्वरूपों में पाए गए किनारे के मामलों को देखते हुए , प्रत्येक तालिका प्रविष्टि के लिए, यदि गुणों की पंक्ति / स्तंभ संयोजन का समर्थन किया जाता है, तो उस संयोजन को कवर करने के लिए कम से कम एक परीक्षण मामला (एक डेटा फ़ाइल) होना चाहिए।
rwong

@rwong मैंने एक उदाहरण जोड़ा, लेकिन मुझे यकीन नहीं है कि यह आपको एक विचार देता है। मुझे लगता है कि मेरी समस्या बढ़त के मामलों के साथ एक आम है, अर्थात। क्या मुझे कोई याद किया है? हालांकि, डेटा-संचालित परीक्षण दिलचस्प दिखता है। धन्यवाद!
sdasdadas 16

7
इसके अलावा, मैंने अभी इस पर ध्यान दिया है, लेकिन मेरे किनारे के मामले सचमुच किनारे के मामले हैं।
सूरदासदास

1
हैंड-क्राफ्ट परीक्षण फाइलें क्यों नहीं, और फिर हमेशा उसी के खिलाफ चलती हैं?
बोबसन

@ बोबसन जनरेटर का उपयोग करने से थोड़ा खराब है। उस स्थिति में मुझे किनारे के मामलों की याद आ सकती है (जैसा कि मैं शायद अब याद कर रहा हूं), लेकिन मैं अपनी टाइपिंग में त्रुटियों को भी पेश कर सकता हूं। और बड़ी फ़ाइलों के साथ, उन्हें अपने दम पर बनाने में काफी समय लगेगा।
sdasdadas

जवाबों:


19

पहले, आपके लक्ष्य क्या हैं, इसके बारे में बात करते हैं:

  • आप स्पष्ट रूप से "फ़ाइल स्वरूपों" का परीक्षण नहीं करना चाहते हैं - आप अपने विभिन्न FileReaderकार्यान्वयनों का परीक्षण करना चाहते हैं

  • आप स्वचालित परीक्षणों द्वारा यथासंभव विभिन्न प्रकार की त्रुटियों को ढूंढना चाहते हैं

पूर्ण रूप से उस लक्ष्य तक पहुंचने के लिए, IMHO को आपको विभिन्न रणनीतियों को संयोजित करना होगा:

  • पहला, वास्तविक इकाई परीक्षण: आपके FileReaderकार्यान्वयन में कई अलग-अलग भाग और कार्य शामिल होंगे। छोटे परीक्षण लिखें जो उनमें से प्रत्येक को अलगाव में परीक्षण करते हैं; अपने कार्यों को इस तरह से डिज़ाइन करें कि उन्हें वास्तव में किसी फ़ाइल से डेटा पढ़ने की आवश्यकता न हो। इस तरह के परीक्षण आपको अपने अधिकांश किनारे के मामलों का परीक्षण करने में मदद करेंगे।
  • दूसरी, उत्पन्न फाइलें: वे हैं जिन्हें मैं एकीकरण परीक्षण कहूंगा। ऐसी फाइलें आपको अंक 1 से अलग विफलताओं को ट्रैक करने में मदद करेंगी, उदाहरण के लिए, विशिष्ट मापदंडों के संयोजन, फाइल एक्सेस में त्रुटियां आदि। अच्छे परीक्षण मामलों को बनाने के लिए, कुछ क्लासिक तकनीकों जैसे समूह परीक्षण मामलों के बारे में सीखना भी मददगार होगा। समतुल्यता वर्ग या सीमा मूल्य परीक्षण। इस बारे में अधिक जानने के लिए ग्लेनफोर्ड मायर्स की इस पुस्तक की एक प्रति प्राप्त करें । सॉफ्टवेयर परीक्षण के बारे में विकिपीडिया लेख एक अच्छा संसाधन, भी है।
  • तीसरा, वास्तविक दुनिया डेटा प्राप्त करने का प्रयास करें: यह सत्यापित करना कठिन हो सकता है कि इन फ़ाइलों का मूल्यांकन आपके द्वारा सही तरीके से किया गया है FileReader, लेकिन यह ऐसा करने के लिए इसके लायक हो सकता है क्योंकि अक्सर यह पता चलता है कि कीड़े पहले दो रणनीतियों द्वारा प्रकट नहीं हुए हैं। कुछ लोग इन प्रकार की चीजों को "एकीकरण परीक्षण" भी कहेंगे, अन्य "स्वीकृति परीक्षण" पसंद करते हैं, लेकिन वास्तव में यह शब्द वास्तव में मायने नहीं रखता है।

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

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


बहुत बढ़िया जवाब, और मैं अपने प्रश्न का शीर्षक बेहतर ढंग से प्रतिबिंबित करने के लिए संपादित करूँगा। धन्यवाद!
sdasdadas
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.