ASP.NET - यूनिट परीक्षण MembershipProvider

Question

मैं, इकाई परीक्षण MembershipProvider कोशिश कर रहा हूँ लेकिन मैं यह पता लगाने नहीं कर सकते कि कैसे या इसके इकाई परीक्षण के लिए किसी भी आवश्यकता है कि क्या ...

मेरे व्यापार परत:

public interface IAccountService 
{ 
    MembershipCreateStatus CreateUser(string userName, string password, string email); 
} 

public class AccountService : IAccountService 
{ 
    private readonly MembershipProvider provider; 

    public AccountService() : this(null) { } 
    public AccountService(MembershipProvider providera) 
    { 
     this.provider = providera ?? Membership.Provider; 
    } 

    public MembershipCreateStatus CreateUser(string userName, string password, string email) 
    { 
     if (String.IsNullOrEmpty(userName)) throw new ArgumentException("Value cannot be null or empty.", userName); 
     if (String.IsNullOrEmpty(password)) throw new ArgumentException("Value cannot be null or empty.", password); 
     if (String.IsNullOrEmpty(email)) throw new ArgumentException("Value cannot be null or empty.", email); 

     MembershipCreateStatus status; 
     provider.CreateUser(userName, password, email, null, null, true, null, out status); 

     return status; 
    } 
} 

एकमात्र उदाहरण जिन्हें मैंने अभी तक पाया है, स्थानीय डेटाबेस सेटअप के साथ "MockMembershipProvider" की आवश्यकता है ... मेरे लिए काफी अजीब लगता है।

अग्रिम धन्यवाद।

Answer 1

कुछ कारणों से "स्थानीय डेटाबेस सेटअप के साथ MockMembershipProvider" होने के कारण कुछ कारणों से अजीब है।

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

बाकी का उत्तर इस धारणा पर आधारित है कि आप अपने यूनिट परीक्षण में डीबी को हिट नहीं करना चाहते हैं।

---

चाहे आप सदस्यता प्रदाता का परीक्षण करना चाहते हैं, वहां पर क्या हो रहा है इस पर निर्भर करेगा।

1. यदि सदस्यता प्रदाता कस्टम लिखा गया है और इसमें व्यावसायिक तर्क शामिल है तो इसे इकाई परीक्षण किया जाना चाहिए। यदि ऐसा है तो आप को सदस्यता प्रदाता के भीतर एक नकली DAO ऑब्जेक्ट बनाने की आवश्यकता है ताकि सदस्यता प्रदाता को डेटाबेस को मारने के बिना इकाई परीक्षणों द्वारा उपयोग किया जा सके।

2. यदि सदस्यता प्रदाता बस डेटाबेस पहुंच (या तो सीधे या डेटा एक्सेस टियर पर कॉल अग्रेषण के साथ) ले रहा है, आपको इकाई का परीक्षण नहीं करना चाहिए। यदि आप माइक्रोसॉफ्ट एएसपीनेट सदस्यता प्रदाता का उपयोग कर रहे हैं तो आपको इसका परीक्षण नहीं करना चाहिए।

   इसके बजाय आपको AccountService कक्षा के भीतर उपयोग करने के लिए एक नकली MembershipProvider बनाना चाहिए। आप नकली का उपयोग कर निर्माता इंजेक्शन इंजेक्षन जाएगा, यह निम्न बॉयलरप्लेट कोड

   public AccountService() : this(null) { } 
   public AccountService(MembershipProvider providera) 
   { 
       this.provider = providera ?? Membership.Provider; 
   } 
   

   इस कोड के प्रयोजन की सुविधा वैकल्पिक कार्यान्वयन के निर्माता इंजेक्शन (जो mocks भी शामिल है) है।

   [Test] 
       public void ExampleTestWithAHandRolledMock() 
       { 
        //arrange 
        var mockMembershipProvider = new MockMembershipProvider();//no db access in this mock implementation 
        var accountService = new AccountService(mockMembershipProvider); 
        //act 
        accountService.CreateUser("foo", "bar", "baz"); 
        //assert 
        Assert.IsTrue(mockMembershipProvider.MockUserExists("foo","bar","baz");//added a method to mock to confirm user was added 
       }