एएसपीनेट एमवीसी आरटीएम टेस्ट नामकरण सम्मेलन

Question

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

GetResource_WhenResourceFileExists_ShouldReturnResources()

लेकिन जब मैं अपने नियंत्रकों के लिए परीक्षण लिख रहा हूँ, मैं आमतौर पर ही नाम के दो तरीके है। अनुरोध प्राप्त करने के लिए पैरामीटर के बिना एक और पदों के साथ एक। क्या दोनों के बीच अंतर करने के लिए यहां कोई अच्छा नामकरण सम्मेलन है?

1. 
LogIn_WithParameters_ShouldReturnLogInView() 
LogIn_WithoutParameters_WhenAuthenticationFailed_ShouldReturnLogInView() 
LogIn_WithoutParameters_WhenAuthenticationPassed_ShouldReturnProfileRedirect() 

2. 
LogIn_Get_ShouldReturnLogInView() 
LogIn_Post_WhenAuthenticationFailed_ShouldReturnLogInView() 
LogIn_Post_WhenAuthenticationPassed_ShouldReturnProfileRedirect() 

3. 
LogIn_ShouldReturnLogInView() 
LogIn_WhenCalledWithParametersAndAuthenticationFailed_ShouldReturnLogInView() 
LogIn_WhenCalledWithParametersAndAuthenticationPassed_ShouldReturnProfileRedirect() 

कोई राय:

मैं के बारे में सोच सकते हैं?

Answer 1

मुझे लगता है कि यह एक आदर्श उदाहरण है कि क्यों यूनिट परीक्षणों के लिए कठोर नामकरण सम्मेलन अवांछित हैं।

आपकी प्रस्तावित योजना केवल तभी काम करेगी जब आपके पास दो विधि अधिभार हों: एक के साथ एक और पैरामीटर के बिना। यह उस परिदृश्य तक विस्तारित नहीं है जहां आपके पास विभिन्न पैरामीटर के साथ एक से अधिक अधिभार हैं।

व्यक्तिगत तौर पर मैं एक बहुत हारने नामकरण परंपरा के रूप में

[Action][Will|Should|Is|...][Result] 

यह मुझे मेरे परीक्षण

SutIsPathResolutionCommand 
ExecuteWithNullEvaluationContextWillThrow 
ExecuteWillAddDefaultClaimsTransformationServiceWhenNoConnectionServiceIsAvailable 

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

Answer 2

मैं निम्न स्वरूप जो मेरे लिए बहुत अच्छी तरह से काम करता है का उपयोग करें:

[TestFixture]  
public class Log_in_with_parameters_should 
{ 
    [Test] 
    public void Return_the_log_in_view() {} 
} 

[TestFixture]  
public class Log_in_without_parameters_should 
{ 
    [Test] 
    public void Return_the_log_in_view_when_the_authentication_failed() {} 

    [Test] 
    public void Redirect_to_the_profile_when_the_authentication_passed() {} 
} 

Answer 3

एक विकल्प है, जो मैं नहीं चाहता कि विशेष रूप से की तरह, नियंत्रक क्रियाएँ अलग-अलग नाम दे रहा है, लेकिन फिर करने के लिए का उपयोग कर उनका नाम बदल ActionName विशेषता:

public ActionResult Login() { 
    // ... code ... 
    return View(); 
} 

[HttpPost] 
[ActionName("Login")] 
public ActionResult LoginPost(... some params ...) { 
    // ... more code ... 
    return View(); 
} 

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

Answer 4

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

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

Answer 5

मैं अपने प्रश्न में से एक के लिए एक समान नामकरण परंपरा का उपयोग यानी method_scenario_expected मुझे लगता है कि आप "परिदृश्य" भाग के बारे में अधिक विस्तार से बता देना चाहिए - अगर आप पैरामीटर प्रदान करने के कर रहे हैं - पाठक जानते हैं कि उनके बारे में speacial है चलो ।

ध्यान रखें कि आपके परीक्षणों का नामकरण इस तरह से अधिक है "टीडीडी अयस्किटेड" और कोई बीडीडी - बीडीडी परीक्षण नाम नियमों और "व्यवहार: के बारे में होना चाहिए।

यदि आपको लगता है कि वर्तमान नामकरण सम्मेलन कोड पठनीयता को hwlp नहीं करता है - आसपास प्रयोग करने के लिए स्वतंत्र महसूस करें और यह पता लगाएं कि आपके लिए क्या काम करता है।