बैच प्रोसेसिंग के लिए टीडीडी: यह कैसे करें?


14

मुझे RoR के लिए "रेड / ग्रीन / रिफ्लेक्टर" पसंद है, आदि ठीक है।

मेरे दिन की नौकरी में अजगर और अन्य कस्टम टूल में तीसरे पक्ष से बहुत बड़ी फ़ाइलों का बैच प्रसंस्करण शामिल है।

इन फ़ाइलों की विशेषताओं पर मंथन अधिक है, इसलिए बहुत अधिक सुधार लागू होते हैं।

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

Q >> इस तरह के माहौल में TDD सिद्धांतों को कैसे लाया जाए?


1
क्या यह डेटा, या स्रोत कोड, या दोनों पर मंथन है?
rwong

जवाबों:


5

सिर्फ एक FYI करें: यूनिट परीक्षण TDD के बराबर नहीं है। टीडीडी एक प्रक्रिया है, जिसमें इकाई परीक्षण एक तत्व है।

इसके साथ ही, यदि आप इकाई परीक्षण को लागू करना चाहते हैं तो आपके लिए कई काम हो सकते हैं:

सभी नए कोड / संवर्द्धन का परीक्षण किया जाता है

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

डेटा के व्यक्तिगत टुकड़ों का परीक्षण करें

ऐसी चीज़ का परीक्षण करना जिसमें बड़ी मात्रा में डेटा हो सकता है और परीक्षण कवरेज में बहुत सारे किनारे मामले और अंतराल हो सकते हैं। इसके बजाय, 0, 1, कई विकल्पों पर विचार करें। 0 तत्वों, 1 तत्व और कई तत्वों के साथ एक 'बैच' का परीक्षण करें। 1 तत्व के मामले में, विभिन्न अनुमतियों का परीक्षण करें जो उस तत्व के लिए डेटा में हो सकते हैं।

वहां से, किनारे के मामलों (व्यक्तिगत तत्वों के आकार में ऊपरी सीमा, और बैच में तत्वों की मात्रा) का परीक्षण करें। यदि आप नियमित रूप से परीक्षण चलाते हैं, और आपके पास लंबे समय तक चलने वाले परीक्षण (बड़े बैच?) हैं, तो अधिकांश परीक्षण धावक वर्गीकरण की अनुमति देते हैं ताकि आप उन परीक्षण मामलों को अलग से (रात में?) चला सकें।

आपको एक मजबूत आधार देना चाहिए।

वास्तविक डेटा का उपयोग करना

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


3
यदि आवश्यक हो, तो बस यह सुनिश्चित करें कि आप परीक्षण डेटा को उपयुक्त रूप से अनामांकित करते हैं।
फ्रैंक शीयर

1

किसी भी अन्य वातावरण के समान ही।

अपने छोटे से छोटे स्तर पर तर्क को अलग करें। यह आपको प्रक्रिया के लिए नियमों का एक सेट देगा, प्रत्येक नियम आपकी प्रक्रिया के लिए आवश्यक तर्क के एक आइटम को कवर करेगा।

फिर प्रत्येक नियम के लिए एक परीक्षा लिखें। ये टेस्ट फेल हो जाएंगे। परीक्षण को ठीक करने के लिए कोड लिखें।

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


1

एक अच्छी सॉफ्टवेयर रणनीति के साथ शुरुआत करें, फिर टीडीडी लागू करें।

(अस्वीकरण: मुझे गलत "मंथन", या टीडीडी, या दोनों हो सकता है।)

यहां बैच प्रोसेसिंग "डर्टी डेटा" के लिए मेरी सुझाई गई रणनीति है: Specify-Triage-Execute।

  • कड़े और संकीर्ण तरीके से डेटा के विनिर्देश को ड्राफ़्ट करें, फिर भी आने वाले डेटा के बहुमत (कहना, 80% या अधिक) को कवर करेगा। इस विनिर्देश 1 को कॉल करें ।
  • यदि कोई रिकॉर्ड विनिर्देश 1 को पूरा करता है, तो एक ट्राइएज मॉड्यूल (TDD यदि आप चाहें) विकसित करें ।
    • सुनिश्चित करें कि मॉड्यूल बहुत तेज चलता है।
    • मॉड्यूल को सही / गलत लौटना चाहिए: यह या तो सभी नियमों को पूरा करता है, या यह नहीं करता है।
  • एक निष्पादित मॉड्यूल (TDD यदि आप चाहें तो) विकसित करें जो एक रिकॉर्ड को निर्दिष्ट करता है जिसे विशिष्टता 1 को पूरा करने के लिए जाना जाता है, जो आपके ग्राहकों द्वारा आवश्यक कार्य करता है।
  • आने वाले सभी डेटा पर ट्राइएज 1 लागू करें ।
    • परिणाम प्रत्येक रिकॉर्ड के लिए एक बूलियन मान है। यह मूल रूप से आने वाले डेटा को अलग करता है: विशिष्टता 1, या अज्ञात।
    • जब भी ग्राहक की आवश्यकता हो, विनिर्देश १ डेटा पर एक्सक्यूट १ लागू करें ।
  • शेष डेटा का 80% स्वीकार करने के लिए विनिर्देश 1 के नियमों को आराम दें। इस विनिर्देश 2 को कॉल करें ।
  • Triage 2 और Execute 2 विकसित करें । इसे किसी भी डेटा पर लागू करें जो विनिर्देश 1 को पूरा नहीं करता है।
  • आवश्यकतानुसार कई स्तरों तक दोहराएं, जब तक कि शेष डेटा काफी छोटा न हो जाए कि इसे हर दिन मैन्युअल रूप से संसाधित किया जा सके।

दक्षता tidbit:

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

"आपको टीडीडी करने से पहले यह जानना होगा कि आप क्या बनाना चाहते हैं"

Specify-Triage-Execute प्रत्येक स्तर पर आवश्यकताओं को प्रबंधित करने का एक तरीका है और भविष्य के विकास के लिए अनुमति देता है।

(यदि कोई मानक उन तीन चरणों के लिए सही शब्द जानता है, तो कृपया मुझे बताएं, मैं अपने उत्तर संपादित करूंगा।)

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.