क्या यूआई विकसित करते समय टीडीडी अच्छी तरह से लागू होता है?

Question

उपयोगकर्ता इंटरफ़ेस विकसित करते समय टीडीडी का उपयोग करने के संबंध में आपकी राय और अनुभव क्या हैं?

मैं कुछ समय से इस प्रश्न के बारे में सोच रहा हूं और केवल अंतिम निर्णय तक नहीं पहुंच सकता। हम सिल्वरलाइट प्रोजेक्ट शुरू करने जा रहे हैं, और मैंने Microsoft Silverlight Unit Test Framework को टीडीडी के साथ दिमाग में देखा है, लेकिन मुझे यकीन नहीं है कि सामान्य रूप से यूआई-विकास के दृष्टिकोण को कैसे लागू किया जाए - या विशेष रूप से सिल्वरलाइट के लिए।

संपादित करें: सवाल अगर यह यूआई-विकास के लिए TDD उपयोग करने के लिए, कैसे चिंताओं की जुदाई करने के बारे में नहीं व्यावहारिक बात यह है के बारे में है।

Answer 1

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

इसी तरह, जब तक आप नए घटक लिख रहे हों, तब तक जीयूआई घटकों का परीक्षण न करें। अपनी नौकरी करने के लिए ढांचे पर भरोसा करें।

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

Answer 2

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

Answer 3

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

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

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

कुछ परीक्षण परीक्षण से बेहतर है, लेकिन यह बेहतर हो सकता है।

Answer 4

हां, आप वेब ऐप्स के जीयूआई परीक्षण के लिए टीडीडी का बहुत प्रभाव डाल सकते हैं।

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

यह उन चीजों को पकड़ने के लिए वास्तव में साफ है जो परीक्षक हमेशा क्लिक करना भूल जाते हैं; वे भी परीक्षण अंधापन मिलता है!

Answer 5

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

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

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

Answer 6

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

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

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

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

फिर, मैं इसे नीचे से काम करता हूं। लगता है कि आपकी टीडीडी पृष्ठभूमि आपको लाभों को बाहर निकालने देगी। रास्ते पर रिफैक्टर भी ....

Answer 7

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

Answer 8

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

यह Humble Dialog Box Pattern है।

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

Answer 9

मुझे लगता है कि this blog post आयुर्वे रहीन द्वारा मेरे प्रश्न का उत्तर व्यावहारिक और ध्वनि दृष्टिकोण का उपयोग करके अच्छी तरह से किया गया है।

परीक्षण यूआई, उदाहरण के लिए, एक आम जगह है जहाँ यह समय और प्रयास के लायक सिर्फ नहीं है: यहाँ पद से कुछ उद्धरण हैं।

...

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

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

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

Answer 10

मेरे कार्यस्थल हम TDD हम बजाय का उपयोग करें और हम वास्तव में इकाई (एक वेब अनुप्रयोग के लिए) हमारे यूआई कोड का परीक्षण Apache Wicket के WicketTester करने के लिए धन्यवाद, लेकिन यह परीक्षण नहीं कर रहा है कि कुछ वर्णनात्मक लेबल एक पाठ क्षेत्र या ऐसा ही कुछ करने से पहले है, परीक्षण करें कि घटकों का पदानुक्रम कुछ हद तक सही है ("लेबल टेक्स्ट फ़ील्ड" के समान सबसेट में है और घटक वे हैं जो वे हैं ("यह लेबल वास्तव में एक लेबल" है)।

दूसरों की तरह पहले से ही कहा गया है, यह निर्धारित करने के लिए असली व्यक्ति पर निर्भर करता है कि यूआई पर उन घटकों को कैसे रखा जाता है, प्रोग्रामर नहीं, खासकर जब प्रोग्रामर के पास ऑल-इन-वन/अस्पष्ट कमांड लाइन टूल्स करने की प्रवृत्ति होती है यूआई का उपयोग करना आसान है।