डिजाइन करने के लिए टीडीडीइंग एमवीसी नियंत्रक

Question

मैं एक नई परियोजना (अच्छी तरह से, मौजूदा एक को पुनरारंभ करना) शुरू कर रहा हूं, और सभी लाभों के लिए टीडीडी (एनएचटी के लिए) को अपनाने की कोशिश कर रहा हूं।

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

यह जहाँ मेरे अनिश्चितता की वर्तमान स्थिति में आता है

कहानी पर विचार करें:।

"एक उपयोगकर्ता ऐसा करने में वे नव का विवरण देखने के लिया जाता है, एक विजेट जोड़ने के लिए सक्षम होना चाहिए जोड़ा विजेट। "

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

तो मैंने नियंत्रक के साथ एक नोटिम्प्लेटेड अपवाद को फेंकने के साथ शुरुआत की, फिर एक दृश्य() लौटाया ... निम्नलिखित बात यह थी कि मैंने टेस्ट पास करने के लिए सबसे छोटी लाइनें लिखी थीं।

[TestFixture] 
public class WidgetControllerTester 
{ 

    [Test] 
    public void Create_IfBusinessModelIsValid_ReturnRedirectToRouteResultToDetailsAction() 
    { 
    // Arrange 
     var currentUser = new User 
           { 
            DisplayName = "Fred", 
            Email = "fred@widgets.com", 
            Password = "pass", 
            Status = UserStatus.Active 
           }; 
     var model = new WidgetModel(); 
     var controller = new WidgetController(); 
     // Act 
     var actionResult = controller.Create(currentUser, model); 
     // Assert 
     actionResult.AssertActionRedirect().ToAction("Details"); 
    } 
} 

public class WidgetModel 
{ 
} 

public class WidgetController: Controller 
{ 
    public ActionResult Create() 
    { 
     return View("Create"); 
    } 

    [HttpPost] 
    public ActionResult Create(User currentUser, Widget model) 
    { 
     return RedirectToAction("Details"); 
    } 
} 

अब मुझे एहसास है कि अमान्य मॉडल के लिए अतिरिक्त परीक्षण और मॉडल राज्य की जांच अतिरिक्त कहानियों से विकसित होगी।

हालांकि मुझे नियंत्रक के भीतर और कोड चलाने के लिए अतिरिक्त परीक्षणों का लाभ उठाने का एक स्पष्ट मार्ग नहीं दिखाई दे रहा है।

उदाहरण के लिए, मुझे कुछ समय पता है कि मैं कार्यवाही से विजेट सेवा कॉल करना चाहता हूं। क्या मुझे कुछ स्पष्ट याद आ रहा है (पेड़ के सामान के लिए लकड़ी को देखने में सक्षम नहीं है) मैं अतिरिक्त परीक्षणों के साथ नियंत्रक कोड कैसे प्रगति कर सकता हूं?

विजेट सेवा के बारे में बात करते हुए, मुझे उम्मीद है कि मैं एक विजेट सेवापत्र लिखूंगा और नियंत्रक के भीतर संदर्भों के संदर्भ में अधिकतर मजाक किया जाएगा।

कुछ विचार मैं पड़ा है ...

• Create_IfModelIsValid_WidgetIsAddedToRepository नामक एक नया परीक्षण बनाएं, लेकिन कैसे यह स्पष्ट रूप से नियंत्रक कार्रवाई में सेवा कॉल पर नेतृत्व करता है?
• मुझे एक और विस्तृत कहानी लिखनी है जिसमें कहा गया है कि मॉडल को भंडार/डेटाबेस आदि में डालने की आवश्यकता है?
• क्या मैं टीडीडी और एक्सपी के तत्वों को जोड़ रहा हूं?

पढ़ने के लिए धन्यवाद, मैं प्रगति के लिए सर्वोत्तम अभ्यास के लिए किसी भी प्रतिक्रिया और अंतर्दृष्टि की सराहना करता हूं।

जो।

संपादित 27 फ़र, 2010

मैं निम्न आलेख पुनरावृत्ति # 6 मिला - (asp.net पर) का प्रयोग करें टेस्ट संचालित विकास (http://www.asp.net/%28S%28ywiyuluxr3qb2dfva1z5lgeg%29%29/learn/mvc/tutorial-31-cs.aspx) जो बात मैं के बाद था की तरह दर्शाता है, लेकिन वे लगते हैं नियंत्रक को पुन: फैक्टरिंग के रूप में भंडार/सेवा के अतिरिक्त पर विचार करने के लिए ... मैं व्यक्तिगत रूप से सहमत नहीं हूं, क्या मैं गलत हूं?:)

मैं एक परीक्षा लिखने के बारे में सोचने जा रहा हूं जो विवरण कार्रवाई के व्यूडेटा की जांच करता है और मेरे पास एक बार यह प्रश्न अपडेट करता है।

Answer 1

जो। मुझे कभी-कभी एक ही अनिश्चितता महसूस होती है। लेकिन मुझे यह भी लगता है कि आप जो कुछ खो रहे हैं वह उन सामने की कहानियां है। सबसे पहले, आपको वास्तविक डेवलपर आवश्यकताओं को बनाने के लिए अपनी कहानी को केवल एक टैड विघटित करना चाहिए। यहां मेरा मतलब है:

"उपयोगकर्ता एक विजेट जोड़ने में सक्षम होना चाहिए, ऐसा करने के लिए उन्हें नए जोड़े गए विजेट के विवरण देखने के लिए लिया जाता है।" जहां उपयोगकर्ता से आया -

"एक उपयोगकर्ता ने":

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

"जोड़ें एक विजेट "- क्या (मुझे कार्यान्वयन का मतलब नहीं है, मैं बस यह इंगित कर रहा हूं कि इसका मतलब यह है कि आप या तो एक भंडार या सेवा को मारने जा रहे हैं, जब तक कि 'add' का अर्थ यह नहीं है कि इसे चल रहे इंस्टेंस में जोड़ें और आपको दृढ़ता की आवश्यकता नहीं है)? क्या विजेट को इस बिंदु पर मान्य होना चाहिए, या अमान्य विड्ज को सहेजा जा सकता है और बाद में वैध बनाया जा सकता है? यह मेरा परीक्षण करता है कि एक रिपोजिटरी या सेवा में एक विधि हिट होती है (सेव(), डालें(), ऐड(), जो कुछ भी (विधि के आंतरिक नहीं, जब तक कि आप अपनी सेवा/रेपो का परीक्षण नहीं कर लेते, केवल नियंत्रक इसे कॉल करके अपना काम करता है), वैध/अमान्य विजेट पर क्या होता है (आपको अपनी कहानी को थोड़ा विस्तारित करने या वैध/अमान्य विजेट्स पर क्या होना चाहिए) को कवर करने के लिए एक कहानी जोड़ें)

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

यह सिर्फ एक त्वरित शॉट है, लेकिन मूल रूप से यह विचार प्रक्रिया है। आप वही डब्ल्यू/अन्य कहानियां भी कर सकते हैं, और उस मामले के लिए अधिक एप्लिकेशन व्यवहार को कवर करने के लिए नई कहानियां उत्पन्न होती हैं।

आपके डिजाइन पर कुछ विचार आगे बढ़ रहे हैं।

आपका अगला परीक्षण उस पर ध्यान देना चाहिए जो मैंने पहले लिखा था, यह तथ्य है कि नियंत्रक के POST कार्रवाई को बनाना चाहिए 1) आवश्यक डेटा (अपने पैरा) प्राप्त करना चाहिए, 2) विजेट को "जोड़ने" के लिए उस सेवा/भंडार को कॉल करें , 3) संभवतः कुछ जोड़ता है यदि यह असफल हो जाता है (यह आपके डिज़ाइन में है; मुझे पता चला है कि मेरे नियंत्रकों का मानना ​​है कि सभी ठीक हो जाएंगे और मैं गुणों के माध्यम से विफलताओं को संभालता हूं, लेकिन यह 'व्यक्तिगत डिज़ाइन निर्णय) है, 4) विवरण।

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

[Test] 
public void Create_CallsRepository() 
{ 
    // Arrange 
    var currentUser = new User 
          { 
           DisplayName = "Fred", 
           Email = "fred@widgets.com", 
           Password = "pass", 
           Status = UserStatus.Active 
          }; 
    var model = new WidgetModel(); 
    var mockService = new Mock<IService<WidgetModel>(); 
    mockService.Setup(s=>s.Add(model)); //.Returns(whatever) if it returns something 
    var controller = new WidgetController(mockService.Object); 

    // Act 
    var actionResult = controller.Create(currentUser, model); 

    // Assert 
    mockService.Verify(s=>s.Add(model)); 
} 

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