क्या एमवीसी वेब अनुप्रयोगों में नियंत्रक इकाई-परीक्षण योग्य होना चाहिए?

Question

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

हालांकि, ऐसा लगता है कि, उदाहरण के लिए, कुछ एएसपी.नेट एमवीसी डेवलपर्स वास्तव में want their controllersto be unit-testable।

मैं क्या जानना चाहता हूं कि यह वास्तव में वेब विकास में काम करता है। यूनिट परीक्षण के लायक नियंत्रक हैं? क्या उन्हें गैर-तुच्छ अनुप्रयोगों में इकाई-परीक्षण योग्य रूप से कठोर विकास की गति के रूप में डिजाइन करना है? साथ ही, क्या किसी भी वेब ढांचे ने नियंत्रक इकाई-टेस्टेबिलिटी को लागू करने की कोशिश की है? व्यक्तिगत अनुभव स्वागत है।

Answer 1

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

Answer 2

संक्षिप्त उत्तर: "हां" एक "अगर," लंबा उत्तर: "नहीं" के साथ "नहीं"।

इन दिनों मैं मॉडल और व्यावसायिक वस्तुओं के मजबूत यूनिट-परीक्षण कवरेज और ककड़ी के साथ कार्यात्मक परीक्षण कवरेज के पक्ष में नियंत्रक-स्तर इकाई परीक्षणों को याद करता हूं। यहां धारणा यह है कि नियंत्रक अंतर्निहित मॉडलों में डेटा को रूट करने वाली बहुत हल्के वजन वाली वस्तुएं हैं जो व्यावसायिक तर्क के विशाल बहुमत को समाहित करते हैं।

हालांकि, मुझे अभी भी नियंत्रक स्तर पर कुछ नियंत्रण प्रवाह का कुछ बहुत हल्का कवरेज होता है। यह सिर्फ एक सैनिटी-चेक के अधिक होने लगता है।

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

Answer 3

एमवीसी पैटर्न की सबसे अच्छी सुविधाओं में से एक यह है कि नियंत्रकों को दृश्यों द्वारा HTML आउटपुट के अलगाव में परीक्षण किया जा सकता है। पेज जो HTML आउटपुट के साथ तर्क को मिश्रित करते हैं, परीक्षण करना मुश्किल होता है, और यह उन समस्याओं में से एक है जो एमवीसी हल करता है - यह आपके नियंत्रक को तर्क के बारे में सब कुछ बनाता है और आप HTML को पार्स किए बिना इसका परीक्षण कर सकते हैं।

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