क्या परीक्षण डेटा को संस्करण नियंत्रण में जांचा जाना चाहिए?

40

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

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

testing version-control data

— Swiftheart
स्रोत

2

इकाई परीक्षणों के

— एक CVn

19

@ माइकलकॉर्जलिंग:Tests != Test Data

— रॉबर्ट हार्वे

4

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

— बजे एक CVn

84

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

मुझे एक परियोजना की जांच करने में सक्षम होना चाहिए और एक पूर्ण संकलन, निर्माण और पर्यावरण का परीक्षण करना चाहिए।

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

अन्य लोग संस्करण नियंत्रण में सब कुछ जांचने से असहमत हो सकते हैं , लेकिन मैंने अपने पेशेवर अनुभव में पाया है कि यह सुनिश्चित करने के लिए महत्वपूर्ण है कि एक पूर्ण वातावरण को खरोंच से फिर से बनाया जा सके।

20

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

— किलिआन फोथ

4

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

— केनेथ गार्ज़ा

1

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

— थॉमस

1

@ MarnenLaibow-Koser: एक परियोजना जिस पर मैंने प्रत्यारोपित पेसमेकर लीड्स में विद्युत विफलता का पता लगाने के लिए काम किया, उसमें 40GB से अधिक का परीक्षण सूट था। वहाँ कोई VCS अस्तित्व में नहीं है जहाँ उसके साथ व्यवहार करना अप्रिय नहीं है। दो रिपॉजिट होने के बाद खुद का एक प्रशासन परेशानी है, लेकिन यह कभी-कभी बेहतर विकल्प हो सकता है।

— whatsisname

1

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

— user482745

15

यदि आपके द्वारा तैयार किए गए सेटअप फ़ाइलों के बिना परीक्षण बेकार हैं, तो यह आपके वीसीएस में फ़ाइलों को परीक्षण कोड के साथ शामिल करने के लिए समझ में आता है।

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

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

मैं परीक्षण कोड में एक टिप्पणी डालने पर भी विचार करूंगा जो कहता है " foo.pdfसभी परीक्षणों को चलाने के लिए निर्भर करता है ।"

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

— वॉम्बो

7

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

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

— Warbo
स्रोत

2

यदि आप बेतरतीब ढंग से परीक्षण डेटा उत्पन्न कर रहे हैं, तो आपको वास्तव में बाहर जाना चाहिए और प्रतिलिपि प्रस्तुत करने योग्य स्वचालित परीक्षण लिखने के बारे में एक पुस्तक खरीदना चाहिए।

— दाऊद का कहना है कि मोनिका

5

@ डेविडवैलस तो आप पूरे क्षेत्र की तरह कह रहे हैं कि फ़ज़ल टेस्टिंग, प्रॉपर्टी चेकिंग और स्टैटिस्टिकल सॉफ्टवेयर टेस्टिंग न केवल गलत हैं, बल्कि हानिकारक भी हैं?

— वॉम्बो

5

@DavidWallace यादृच्छिक! = अप्राप्य।

— कॉंगसबोंगस

5

@DavidWallace को आप जो चाहें तब कह सकते हैं। रैंडम टेस्ट डेटा, रिकॉर्ड इनपुट, यदि आवश्यक हो, तो पुन: उपयोग करें। चोट की दुनिया के लिए नेतृत्व नहीं करता है।

— congusbongus

2

@DavidWallace "के बजाय यह सोचने के लिए कि कौन से परीक्षण मामलों की वास्तव में ज़रूरत है" का अर्थ "कोई यादृच्छिक परीक्षण नहीं है", इसका मतलब है "न केवल यादृच्छिक परीक्षण"। जैसा कि "आप बग को ढूंढने वाले डेटा को पुन: पेश नहीं कर सकते हैं", क्या आपने वास्तव में उस उत्तर को पढ़ा है जिस पर आप टिप्पणी कर रहे हैं? ;)

— वारबो

0

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

गिट के साथ आप अपने रेपो को प्रदूषित करने से किसी अस्थायी उत्पादन या परीक्षण लॉगिंग को रोकने के लिए एक .itignore सेट कर सकते हैं।

— NickJHoran
स्रोत