ASP.NET WebForms में यूनिट टेस्ट

इकाई परीक्षण

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

यह किसके लिए है? किस बारे में?

यह लेख मेरी तरह ही C # / ASP.NET WebForms कॉर्पोरेट साइट डेवलपर्स को समर्पित है। जो लोग, मेरी तरह, इस तथ्य से बड़े हुए हैं कि ASP.NET WebForms शांत है, लेकिन वास्तव में नहीं। वास्तव में नहीं, क्योंकि वेब फॉर्म यूनिट परीक्षणों का समर्थन नहीं करते हैं, और इसलिए टीडीडी। और लगातार कोड लिखने का एकमात्र व्यावहारिक तरीका यह है कि इसे सोच समझकर पढ़ा जाए। इसलिए मैं पिछले कुछ वर्षों से पीड़ित था, मौजूदा asp.net परियोजनाओं को विकसित कर रहा था, जब तक कि मैं अपनी दृष्टि वापस नहीं ले लेता। आत्मज्ञान पर चर्चा होगी।

थोड़ा इतिहास

अपने गठन के समय, WebForms डेस्कटॉप VB प्रोग्रामर के लिए अभिप्रेत था, जो पहले से CommandButton, ComboBox, और Click Event में महारत हासिल कर चुके थे (मैंने जल्दबाज़ी नहीं की, मैंने भी इस तरह से शुरुआत की!), जिसने इंटरनेट के अभूतपूर्व दिन के बारे में सुना (क्या आपको हर डॉटकॉम बूम याद है?) और इस व्यवसाय में योगदान देने का फैसला किया। इनके लिए, WebForms का आविष्कार किया गया, जिसने वेब पर RAD (रैपिड एप्लिकेशन डेवलपमेंट) की अवधारणा को पूरी तरह से स्थानांतरित कर दिया: फॉर्म, ईवेंट हैंडलर और सीटी के वैकल्पिक गुच्छा पर नियंत्रण।

क्या समस्या है?

और सब कुछ बहुत अच्छा होगा, लेकिन अचानक, यह पता चला कि इस रूप में, एक डेवलपर के लिए व्यावसायिक तर्क को एक प्रस्तुति के साथ मिश्रण करना और सामान प्राप्त करना बहुत आसान है जिसे परीक्षण नहीं किया जा सकता है।
जिन लोगों ने ऊपर प्रोग्रामर के आक्रोश की गहराई को छुआ, यह स्पष्ट है कि समस्या पर्यावरण में है। न केवल एक विश्वसनीय, एक्स्टेंसिबल सिस्टम को डिजाइन करना मुश्किल है, बल्कि ASP.NET भी सभी सींग और खुरों पर टिकी हुई है! यहां बताया गया है कि अगर सब कुछ घटनाओं पर लटका दिया जाए तो एस्कोक्स नियंत्रण का परीक्षण कैसे करें? हाथ सभी परीक्षण नहीं कर सकते।

कैसे हो सकता है?

यह वह जगह है जहां मैं लेख के विषय को सुचारू रूप से और धीरे से दृष्टिकोण करता हूं।

पहले कुछ फोरप्ले

जैसा कि मैंने ऊपर कहा, मूलभूत समस्याओं में से एक व्यापार तर्क और प्रस्तुति को एक साथ मिला रहा है। उन्हें कोनों में भाग देना आवश्यक है। एमवीसी, एमवीपी की किस्मों में से एक का उपयोग करना उचित है। क्योंकि MVP में, दृश्य उपस्थिति को नियंत्रित करता है, और उपयोगकर्ता अनुरोधों को भी परोसता है। प्रस्तुतकर्ता की भूमिका दृश्य के लिए डेटा तैयार करना है, साथ ही उदाहरण के लिए डेटा भंडार के साथ संवाद करना है। मॉडल एक दृश्य मॉडल है, जिसमें एक कंटेनर है जिसमें एक दृश्य प्रदर्शित करने के लिए डेटा है। तो, MVP ASP.NET वर्किंग स्कीम में पूरी तरह से फिट बैठता है: व्यू अभी भी एक ही यूजर कंट्रोल, प्रेजेंटर है, यह एक क्लास है जिसमें बिजनेस लॉजिक है, और मॉडल भी एक क्लास है जिसमें डेटा है।

काम की हंसी यह है: दृश्य प्रस्तुतकर्ता से तब मॉडल लेता है, जब उसे इसकी आवश्यकता होती है, और मौजूद होने पर उपयोगकर्ता के इनपुट के बारे में भी सूचित करता है। प्रस्तुतकर्ता, बदले में, अन्य प्रस्तुतकर्ताओं को देखता है और मांग पर एक मॉडल बनाता है, प्राप्त सभी आंकड़ों को ध्यान में रखता है।

बेडरूम की ओर खींचना शुरू करें

मूल संरचना को समझने के बाद, आप परीक्षण लिखना शुरू कर सकते हैं। यह स्पष्ट है कि पूरी तरह से सब कुछ को कवर करने वाला एक इकाई परीक्षण लिखना अव्यावहारिक है क्योंकि ऐसा परीक्षण उस परीक्षण की तुलना में 2-3 गुना लंबा होगा।
थोड़ा विचार करने के बाद, मैंने संभावित घटक इंटरैक्शन की एक सूची लिखी:

• प्रस्तुतकर्ता डोमेन (डोमेन से मेरा मतलब है डोमेन, अर्थात् रिपॉजिटरी, डेटा वेयरहाउस, आदि)
• देखें- प्रस्तुतकर्ता (प्रस्तुतकर्ता के तरीके कैसे देखें)
• उपयोगकर्ता-दृश्य (उपयोगकर्ता से कौन सा इनपुट आता है)

और तदनुसार निम्न प्रकार के परीक्षण

• प्रस्तुतकर्ता डोमेन की बातचीत प्रस्तुतकर्ता की इकाई परीक्षण द्वारा कवर की गई है।
• दृश्य-प्रस्तुतकर्ता इंटरैक्शन दृश्य परीक्षण इकाई द्वारा कवर किया गया है।
• अंत में, उपयोगकर्ता-दृश्य संपर्क एक एकीकरण परीक्षण (ब्राउज़र स्क्रिप्टिंग) द्वारा कवर किया गया है।

इस लेख में, मैं इकाई परीक्षण दृश्य के बारे में सबसे कठिन बात के बारे में बात करूँगा। निम्नलिखित लेखों में मैं कम जटिल परीक्षणों का वर्णन करूंगा।

चलो चलते हैं!

इसलिए, जैसा कि पहले ही उल्लेख किया गया है, दृश्य एक सामान्य आरएक्सएक्स नियंत्रण है। इस तरह के नियंत्रण को asp.net रनटाइम में एक aspx पृष्ठ पर होस्ट किया जाना चाहिए। ऐसा करने के लिए, आप विधि का उपयोग कर सकते हैं

System.Web.Hosting.ApplicationHost.CreateApplicationHost(Type hostType, string virtualDir, string physicalDir) 

जहाँ hostType MarshalByRefObject से विरासत में मिला हुआ एक प्रकार होना चाहिए, और virtualDir और physicalDir को क्रमशः वर्चुअल पथ और भौतिक पथ का संकेत देना चाहिए। CreateApplicationHost उस होस्ट को लौटाएगा जिसमें HTTP अनुरोध भेजे जा सकते हैं।

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

यदि सिद्धांत रूप में यह अनुरोधों के साथ मुश्किल नहीं है (उदाहरण के लिए, एक पोस्टबैक को अनुकरण करने के लिए, आपको बस सही ढंग से POST अनुरोध मापदंडों की रचना करने की आवश्यकता है), तो यह प्रस्तुतकर्ता को नियंत्रित करने के लिए किसी भी तरह से तुच्छ नहीं है, क्योंकि यह ऐपडोमेन के दूसरी तरफ रहता है।

AppDomain प्रक्रिया में एक सा है। दूसरे शब्दों में, .NET वातावरण सिस्टम प्रक्रिया में निष्पादन योग्य कोड को तार्किक उपप्रकारों में विभाजित करना संभव बनाता है जो एक दूसरे से पृथक होते हैं। हमारे मामले में, CreateApplicationHost एक और AppDomain में एक नया होस्ट बनाता है, और इसलिए हम यूनिट टेस्ट से ऑब्जेक्ट्स को सीधे संबोधित नहीं कर सकते हैं, और तदनुसार हमारे पास अवरोध के दूसरी तरफ प्रस्तुतकर्ता तक कोई पहुंच नहीं है।

सौभाग्य से, प्रॉक्सी कक्षाएं हैं जो संदेशों का उपयोग करके दोनों पक्षों को अनुरोध भेज सकती हैं। आप Google में प्रॉक्सी के बारे में पढ़ सकते हैं (एक अनुरोध जैसे .net remoting प्रॉक्सी)। हमारे लिए यह जानना महत्वपूर्ण है कि परदे के पीछे तरीके कह सकते हैं।

 public class Proxy<T> : MarshalByRefObject { private readonly T _object; public Proxy(T obj) { _object = obj; } public TResult Invoke<TResult>(Func<T, TResult> selector) { return selector(_object); } public void Invoke(Action<T> action) { action(_object); } } 

इसके अलावा, सवाल यह उठता है कि हम दृश्य-प्रस्तुतकर्ता की बातचीत की निगरानी कैसे करेंगे। सादगी के लिए, हम किसी भी नकली रूपरेखा का उपयोग कर सकते हैं जो क्लास कॉल को ट्रैक कर सकते हैं। इस मामले में, मैंने Moq को चुना।

और आखिरी एक डेटा ट्रांसफर कंटेनर है। हमारे पास संचारित करने के लिए बहुत कुछ है: नकली-प्रस्तुतकर्ता के बारे में डेटा, पर्यावरण के बारे में डेटा, अनुरोध के बारे में डेटा, और इसी तरह। आगे की हलचल के बिना, हम टेस्टडेटा क्लास बनाते हैं:

 [Serializable] public class TestData { public Type MockPresenterType { get; set; } public Delegate MockPresenterInitializer { get; private set; } public void SetPresenterMockInitializer<TPresenter>(Action<Mock<TPresenter>> action) where TPresenter : class { this.MockPresenterInitializer = action; this.MockPresenterType = typeof(TPresenter); } } 

उपरोक्त के प्रकाश में, इकाई परीक्षण एल्गोरिथ्म इस तरह दिखता है:

इकाई परीक्षण की ओर से:

1. होस्ट बनाएं और कॉन्फ़िगर करें
2. TestData वर्ग का एक उदाहरण बनाएँ और कॉन्फ़िगर करें
3. वांछित नियंत्रण और टेस्टडाटा के साथ एक अनुरोध भेजें
4. प्रक्रिया प्रतिक्रिया
5. नकली-प्रस्तुतकर्ता सेटिंग्स की जाँच करें

मेजबान से:

1. Default.aspx OnPreInit में आवश्यक नियंत्रण लोड होता है
2. आवश्यक नकली-प्रस्तोता बनाएँ
3. नकली-प्रस्तोता सेटिंग्स लागू करें

और इकाई परीक्षण का एक अनुमानित दृश्य:

 [TestMethod] public void UnitTestView { string physicalPath = Environment.CurrentDirectory.Substring(0, Environment.CurrentDirectory.IndexOf("bin")); TestHost host = (TestHost)ApplicationHost.CreateApplicationHost(typeof(TestHost), "/Testing", physicalDir); TestData testData = new TestData(); testData.SetPresenterMockInitializer<Presenter>( mock => { mock.Setup(m => ...); }); host.AddQueryParameter("ControlToTest", "~/OurView.ascx"); string response = host.ProcessRequest("Default.aspx", testData, null); XDocument doc = XDocument.Parse(response); host.GetPresenterMock<Presenter>().Invoke(mock => mock.Verify(m => m.SomeMethodRan(), Times.Once())); } 

होस्ट की ओर से, Default.aspx.cs कोड बहुत सरल दिखता है:

 public class Default : Page, IRequiresSessionState { private readonly PlaceHolder _phContent = new PlaceHolder(); protected override void FrameworkInitialize() { this.Controls.Add(new LiteralControl(@"<!DOCTYPE html><html><body>")); var form = new HtmlForm(); this.Controls.Add(form); form.Controls.Add(_phContent); this.Controls.Add(new LiteralControl(@"</body></html>")); } protected override void OnPreInit(EventArgs e) { base.OnPreInit(e); var controlToTest = this.Request.QueryString["ControlToTest"]; var testData = (TestData)this.Context.Items["TestData"]; if (controlToTest != null) { Control c = this.LoadControl(controlToTest); Type viewType = get view type from that control if (viewType != null) { object presenter; if (testData.MockPresenterType != null) { var mockType = typeof(Mock<>).MakeGenericType(testData.MockPresenterType); object mock = Activator.CreateInstance(mockType); AppDomain.CurrentDomain.SetData("PresenterMock", mock); presenter = mockType.GetProperty("Object", testData.MockPresenterType).GetValue(mock, null); testData.MockPresenterInitializer.DynamicInvoke(mock); viewType.GetProperty("Presenter").SetValue(c, presenter, null); AppDomain.CurrentDomain.SetData("Presenter", presenter); _phContent.Controls.Add(c); } } 

यहां मैंने जानबूझकर व्यू टाइप खोज के विवरण को छोड़ दिया क्योंकि यह विशुद्ध रूप से व्यक्तिगत है (इसके अलावा, मैंने यह वर्णन नहीं किया कि मैंने एमवीपी पैटर्न कैसे लागू किया है)। प्रमुख बिंदु हैं

• नियंत्रण बनाना और जोड़ना QueryString के पास गया
• एक MockPresenter बनाएँ और इसे AppDomain.SetData के माध्यम से AppDomain में जोड़ें। AppDomain.GetData यूनिट टेस्ट का उपयोग करके हमारे MockPresenter तक पहुँच प्राप्त कर सकेंगे
• डायनामिकइनवोक के लिए एक कॉल जो सेटिंग्स लागू करेगा (मॉक => mock.Setup ...)

साथी टेस्टहॉस्ट वर्ग नीचे दिखाया गया है:

 public class TestHost : MarshalByRefObject { private readonly Dictionary<string, string> _query = new Dictionary<string, string>(); public void AddQueryParameter(string key, string value) { _query.Add(key, HttpUtility.UrlEncode(value)); } private string GetQueryParameters() { StringBuilder sb = new StringBuilder(); foreach (var parameter in _query) { sb.AppendFormat("{0}={1}&", parameter.Key, parameter.Value); } return sb.ToString(); } public string ProcessRequest(string page, TestData testData, string postData) { StringWriter writer = new StringWriter(); TestRequest swr = new TestRequest(page, GetQueryParameters(), writer, testData, postData); HttpRuntime.ProcessRequest(swr); writer.Close(); return writer.ToString(); } public Proxy<Mock<TPresenter>> GetPresenterMock<TPresenter>() where TPresenter : class { object mock = AppDomain.CurrentDomain.GetData("PresenterMock"); return new Proxy<Mock<TPresenter>>((Mock<TPresenter>)mock); } } public class TestRequest : SimpleWorkerRequest { private readonly TestData _testData; private readonly byte[] _postData; private const string PostContentType = "application/x-www-form-urlencoded"; public TestRequest(string page, string query, TextWriter output, TestData testData, string postData) : base(page, query, output) { _testData = testData; if (!string.IsNullOrEmpty(postData)) _postData = Encoding.Default.GetBytes(postData); } public override void SetEndOfSendNotification(EndOfSendNotification callback, object extraData) { base.SetEndOfSendNotification(callback, extraData); HttpContext context = extraData as HttpContext; if (context != null) { context.Items.Add("TestData", _testData); } } public override string GetHttpVerbName() { if (_postData == null) return base.GetHttpVerbName(); return "POST"; } public override string GetKnownRequestHeader(int index) { if (index == HeaderContentLength) { if (_postData != null) return _postData.Length.ToString(); } else if (index == HeaderContentType) { if (_postData != null) return PostContentType; } return base.GetKnownRequestHeader (index); } public override byte[] GetPreloadedEntityBody() { if (_postData != null) return _postData; return base.GetPreloadedEntityBody(); } } 

धुआं टूटना

यह सब है, इस स्तर पर आपके पास पहले से ही asp.net webforms के लिए सुरुचिपूर्ण इकाई परीक्षण (जितना संभव हो उतना) लिखने का अवसर है। बेशक, यदि आपके पास एक अन्य वातावरण का उपयोग करने का अवसर है, तो इकाई परीक्षणों के लिए अधिक अनुकूल, हर तरह से, जैसा कि मेरे अमेरिकी सहयोगियों का कहना है। लेकिन अगर यह नहीं है, लेकिन आप अधिक स्थिर कोड लिखना चाहते हैं, तो अब यह संभव है।

वैसे, मैंने प्रूफ-ऑफ-कॉन्सेप्ट के लिए केवल सबसे जरूरी कोड का हवाला दिया है। उदाहरण के लिए, मैंने पोस्टबैक बनाने और परीक्षण डेटा स्थानांतरित करने की प्रक्रिया को छोड़ दिया, साथ ही परीक्षण के लिए नियंत्रण तैयार किया। यदि रुचि है, तो मैं इस बारे में लिख सकता हूं, साथ ही साथ एमवीपी के मेरे कार्यान्वयन के बारे में, और अन्य 2 प्रकार के परीक्षणों के बारे में जो ऊपर उल्लेखित हैं।

आपका ध्यान देने के लिए धन्यवाद।