यूनिट परीक्षण फ्रंट एंड लॉजिक

Question

हमने हालिया परियोजना पर यूनिट परीक्षण फ्रंट एंड लॉजिक पेश करने का प्रयास किया है और परीक्षणों के मूल्य पर सवाल उठाए जा रहे हैं।

हम परीक्षण की समीक्षा नहीं कर रहे थे, इसलिए उनकी गुणवत्ता खराब है, डेवलपर्स ने खराब परीक्षणों की नकल की और अधिक खराब परीक्षण किए हैं और इसलिए हमारे पास बहुत सारे बकवास परीक्षण हैं।

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

मैं लोगों को सोचने में कैसे लगा सकता हूं कि फ्रंट एंड टेस्ट मूल्यवान हैं और क्या मुझे किसी को भी मुझे इंगित करने के लिए कोई अच्छा संसाधन मिला है, मुझे इसके साथ वापस लाने के लिए?

धन्यवाद ...

Answer 1

यूनिट सामने अंत तर्क का परीक्षण अत्यंत कठिन के बाद से वहाँ कई भागों है कि यह सामने अंत और क्लाइंट साइड परिवर्तन सभी को प्रभावित कर सकता आवेदन प्रतीत होता है करने के लिए सर्वर साइड कोड में परिवर्तन की तरह बना रहे हैं।

Google परीक्षण blog पर उन्होंने एमवीपी के सभी हिस्सों का परीक्षण करने के मूल्य और महंगे हिस्सों को दबाकर AJAX परीक्षण करने के मूल्य के बारे में बात की here। विभिन्न परीक्षणों here के बारे में Misko Hevery बात करती है और मुझे लगता है कि फ़्रंट एंड परीक्षण अपने बड़े परीक्षण श्रेणी में आते हैं इसलिए हमेशा मिथ्या नकारात्मक/सकारात्मक मौका है, लेकिन वे क्योंकि वे अभी भी मूल्य का एक बहुत की पेशकश हल हो की जरूरत है

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

---

Answer 2

मेरे लिए सवाल व्यापार बंद परीक्षण और कीड़े कि अन्यथा पकड़ा नहीं किया जाएगा पकड़ने की संभावना को बनाए रखने की लागत के बीच होगा। संभवतः आपके पास वास्तविक यूआई का कुछ दृश्य परीक्षण होगा (आप अन्यथा सौंदर्यशास्त्र का परीक्षण करने के लिए वास्तव में अच्छा प्रदर्शन करेंगे)।

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

मुझे संदेह है कि मनाने के लिए एक तरीका धीरे-धीरे आगे बढ़ना है। शुरुआत में कम प्रयासों को खोजने का प्रयास करें।

Answer 3

टूटी हुई खिड़की को ठीक करें। यहां सिद्धांत http://en.wikipedia.org/wiki/Fixing_Broken_Windows

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

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

Answer 4

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

उदाहरण के लिए, कुछ टीमों अंत की तरह बेकार परीक्षण के बहुत सारे लेखन:

Given a button, when the button is clicked, the event handler should fire.