2009-06-19 20 views
5

मुझे यह सुनिश्चित करने के लिए एक यूनिट परीक्षण की आवश्यकता है कि मैं छुट्टी के घंटे ठीक से जमा कर रहा हूं। लेकिन छुट्टी के घंटे एक व्यापार नियम के अनुसार जमा होते हैं, यदि नियम बदलता है, तो इकाई परीक्षण टूट जाता है।यूनिट परीक्षण व्यवसाय नियमों को कैसे करें?

क्या यह स्वीकार्य है? क्या मुझे एक विधि के माध्यम से नियम का पर्दाफाश करना चाहिए और उसके बाद यह विधि मेरे कोड और मेरे परीक्षण दोनों से कॉल करें ताकि यह सुनिश्चित किया जा सके कि इकाई परीक्षण इतना नाजुक नहीं है?

मेरा प्रश्न है: इकाई परीक्षण व्यवसाय नियमों का सही तरीका क्या हो सकता है?

+3

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

उत्तर

5

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

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

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

3

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

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

0

यह सही लगता है कि नियमों में बदलाव होने पर परीक्षण विफल रहता है - इसकी अपेक्षा की जा सकती है।

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

बेशक, यह अत्यधिक तर्क के प्रकार पर निर्भर करता है कि आप परीक्षण कर रहे हैं, और हमेशा लागू नहीं हो सकते हैं।

1

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

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

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

जब आप नई रणनीति के साथ पूरी तरह से कर रहे हैं, तो आप ग्राहक में रणनीति को प्रतिस्थापित कर सकते हैं।

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

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

-1

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

+0

यह ऑब्जेक्ट लागू करने वाले ऑब्जेक्ट के तहत परतों का मज़ाक उड़ाकर पूरी तरह गलत है, आप पूरी तरह से एक इकाई में व्यापार परत को अलग कर सकते हैं और इसलिए यूनिट परीक्षण कर सकते हैं। – Walfrat

+0

विश्लेषण और डिज़ाइन के बाद एक व्यापारिक नियम कोड की कई इकाइयों पर असर डाल सकता है, क्या आप नकल करना चाहते हैं? आप व्यवसाय नियम का शुद्ध कार्यान्वयन कैसे करते हैं? –

+0

बेशक, लेकिन बात क्या है? बनाए रखने या एकल इकाई परीक्षणों के लिए एक विशाल परीक्षण होने के बाद? – Walfrat

संबंधित मुद्दे