यूआई

Question

में किए गए व्यावसायिक तर्क के साथ यूनिट परीक्षण डेटाबेस एप्लिकेशन मैं अपने द्वारा एक बड़ा आवेदन (कोड की 50k + रेखाएं) प्रबंधित करता हूं, और यह कुछ महत्वपूर्ण व्यावसायिक कार्रवाइयों का प्रबंधन करता है। कार्यक्रम का सरल वर्णन करने के लिए, मैं कहूंगा कि यह डेटाबेस से डेटा प्रदर्शित करने और बदलने की क्षमता वाला एक फैंसी यूआई है, और यह लगभग 1,000 किराये इकाइयों का प्रबंधन कर रहा है, और लगभग 3k किरायेदारों और सभी वित्त।

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

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

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

Answer 1

मैं कुछ टूल का उपयोग करके शुरू करूंगा जो यूआई के माध्यम से एप्लिकेशन का परीक्षण करेंगे। ऐसे कई टूल हैं जिनका उपयोग टेस्ट स्क्रिप्ट बनाने के लिए किया जा सकता है जो उपयोगकर्ता को एप्लिकेशन के माध्यम से क्लिक करने का अनुकरण करता है।

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

हम यूनिट परीक्षणों के लिए उपयोग किए जाने वाले एक अलग डेटाबेस वाले डेटाबेस इंटरैक्शन का परीक्षण करते हैं। इस तरह हमारे पास एक स्थिर और नियंत्रित डेटासेट है ताकि अनुरोध और प्रतिक्रिया की गारंटी दी जा सके। फिर हम विभिन्न परिदृश्यों को अनुकरण करने के लिए सी # कोड बनाते हैं। हम इसके लिए nnnit का उपयोग करें।

Answer 2

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

Answer 3

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

Answer 4

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

रिफैक्टरिंग प्रक्रिया में आपको संभवतः उन बग्स मिलेंगे जिन्हें आप अस्तित्व में नहीं जानते थे और अंत में, एक बेहतर प्रोग्रामर बनें!

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

Answer 5

मुझे लगता है कि यह हमेशा एक अच्छा विचार यूआई से अपने व्यापार तर्क अलग करने के लिए है। आसान यूनिट परीक्षण और विस्तारशीलता सहित इसमें कई लाभ हैं। आप पैटर्न आधारित प्रोग्रामिंग का भी उल्लेख करना चाहेंगे। यहां एक लिंक http://en.wikipedia.org/wiki/Design_pattern_(computer_science) है जो आपको डिज़ाइन पैटर्न को समझने में मदद करेगा।

एक चीज जो आप अभी कर सकते हैं, आपके यूआई कक्षाओं के भीतर सभी व्यावसायिक तर्क और अलग-अलग व्यावसायिक आधार कार्यों को अलग करते हैं और प्रत्येक यूआई कन्स्ट्रक्टर या पेज_लोड में यूनिट टेस्ट कॉल होते हैं जो प्रत्येक व्यावसायिक कार्यों का परीक्षण करते हैं। बेहतर पठनीयता के लिए आप व्यवसाय कार्यों के आसपास #region टैग लागू कर सकते हैं।

अपने दीर्घकालिक लाभ के लिए, आप डिजाइन पैटर्न का अध्ययन करना चाहिए। एक पैटर्न चुनें जो आपकी परियोजना की ज़रूरतों को पूरा करता है और डिज़ाइन पैटर्न का उपयोग करके अपनी परियोजना को फिर से करें।

Answer 6

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

Answer 7

सबसे पहले, मैं यूनिट परीक्षण के बारे में अच्छी किताब पढ़ने की सिफारिश करता हूं, जैसे The Art Of Unit Testing। आपके मामले में, यह आपके मौजूदा कोड पर टेस्ट प्रेरित विकास प्रदर्शन करने के लिए एक छोटे से देर हो चुकी है, लेकिन यदि आप इसे चारों ओर अपने इकाई परीक्षण लिखना चाहते हैं, तो यहाँ मैं क्या सिफारिश करेंगे है:

1. कोड पृथक आप परीक्षण करना चाहते कोड पुस्तकालयों में (यदि वे पहले से ही पुस्तकालयों में नहीं हैं)।
2. सबसे अधिक आम उपयोग परिदृश्यों बाहर लिखें और उन्हें अपने कोड पुस्तकालयों का उपयोग करता है एक आवेदन करने के लिए अनुवाद करते हैं।
3. सुनिश्चित करें कि आपके परीक्षण कार्यक्रम काम करता है के रूप में आप यह करने की उम्मीद करते हैं।
4. एक परीक्षण ढांचे का उपयोग कर इकाई परीक्षण में अपने परीक्षण कार्यक्रम में रूपांतरित करें।
5. हरे रंग की रोशनी प्राप्त करें। यदि नहीं, तो आपके यूनिट परीक्षण दोषपूर्ण हैं (मानते हैं कि आपके कोड पुस्तकालय काम करते हैं) और आपको कुछ डिबगिंग करना चाहिए।
6. अपने यूनिट परीक्षणों के कोड और परिदृश्य कवरेज को बढ़ाएं: यदि आपने अप्रत्याशित परिणाम दर्ज किए हैं तो क्या होगा?
7. फिर हरे रंग की रोशनी प्राप्त करें। यदि यूनिट परीक्षण विफल रहता है, तो संभवतः आपकी कोड लाइब्रेरी विस्तारित परिदृश्य कवरेज का समर्थन नहीं करती है, इसलिए यह समय को पुन: सक्रिय कर रहा है!

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

गुड लक (आप इसे की आवश्यकता होगी!)

Answer 8

मैं अत्यधिक लेख Working Effectively With Legacy Code पढ़ने की सलाह देते हैं। यह आपके द्वारा पूरा करने की कोशिश कर रहे कार्यों के लिए एक व्यावहारिक रणनीति का वर्णन करता है।

Answer 9

मैं माइकल फेदर द्वारा Working Effectively with Legacy Code पुस्तक को चुनने की सलाह दूंगा।इससे आपको अपने कोडबेस में परीक्षण कवरेज धीरे-धीरे बढ़ाने और रास्ते में डिज़ाइन में सुधार करने के लिए कई तकनीकें दिखाई देगी।

Answer 10

की तुलना में प्रारंभिक परीक्षण परीक्षण शुरू करने का कोई बेहतर तरीका नहीं है - इसमें लंबा समय नहीं लगता है, यह मजेदार और नशे की लत है। लेकिन केवल तभी यदि आप टेस्टेबल कोड पर काम कर रहे हैं।

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

मैं एक इकाई परीक्षण ढांचे को डाउनलोड करने की सलाह देता हूं, जैसे कि NUnit या XUnit.Net। इनमें से अधिकतर ढांचे में ऑनलाइन दस्तावेज़ीकरण है जो NUnit Quick Start जैसे संक्षिप्त परिचय प्रदान करता है। पढ़ें कि, तो एक सरल, आत्म निहित वर्ग चुनें:

• अन्य वर्गों पर कुछ या कोई निर्भरता है - कम से कम जटिल कक्षाओं पर नहीं।
• कुछ व्यवहार है: गुणों के समूह के साथ एक साधारण कंटेनर वास्तव में आपको इकाई परीक्षण के बारे में बहुत कुछ नहीं दिखाएगा।

उस कक्षा में अच्छा कवरेज प्राप्त करने के लिए कुछ परीक्षण लिखने का प्रयास करें, फिर परीक्षणों को संकलित करें और चलाएं।

एक बार जब आप इसे लटका लेंगे, तो refactor your existing code के अवसरों की तलाश करना शुरू करें, खासकर जब नई सुविधाएं जोड़ना या बग फिक्स करना। जब उन रिफैक्टरिंग उपरोक्त मानदंडों को पूरा करने वाले वर्गों का नेतृत्व करते हैं, तो उनके लिए कुछ परीक्षण लिखें। एक बार जब आप इसका उपयोग कर लेंगे, you can start by writing tests।

Answer 11

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