C # और NUnit का उपयोग करके GUI ऐप के लिए यूनिट टेस्ट कैसे करें


16

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

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

संपादित करें:
कृपया ध्यान दें कि यह प्रश्न NUnit और मेरे निष्पादन योग्य के बीच संबंधों को कैसे संरचित करता है - एक DLL के विपरीत - और प्रस्तुति और व्यावसायिक तर्क को अलग करने के तरीके के बारे में नहीं।
/ संपादित करें

तो मेरा सवाल है:

  1. क्या यूनिट परीक्षणों के साथ एक सरल जीयूआई एप्लिकेशन को कॉन्फ़िगर करने के लिए एक विशिष्ट / अनुशंसित तरीका है जो मुझे राज्य और व्यवहार की पर्याप्त रूप से जांच करने की अनुमति देता है, जो कि मेरे पास मौजूद उपकरणों का उपयोग करते हुए और बिना इंजीनियरिंग का सहारा लिए?
  2. क्या मैंने NEnit को EXE (जब एक DLL के विपरीत) का परीक्षण किया है, तो जिस तरह से इसे लागू / कॉन्फ़िगर किया जाना चाहिए, उसके बारे में कुछ मौलिक याद किया गया है?
  3. क्या आप मुझे इस बात के उदाहरणों की दिशा में प्रदान या इंगित कर सकते हैं कि यह सब कैसे प्राप्त करें?

मुझे लगता है कि ऐसा करने का एक से अधिक तरीका हो सकता है इसलिए मैं आपके अनुभव के आधार पर विशिष्ट कार्यान्वयन दिशानिर्देशों की तलाश कर रहा हूं।


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

1
@ बर्नार्ड यह प्रश्न परीक्षण के लिए जीयूआई बिछाने के बारे में नहीं है। मैं स्वाभाविक रूप से अपने सभी ऐप्स - यहां तक ​​कि तुच्छ लोगों को भी परत करता हूं - ताकि वास्तव में मेरे लिए कोई समस्या न हो। मैंने सवाल को सूट किया है, और मुझे आशा है कि यह किसी भी गलतफहमी को दूर करता है। :)
रॉबिन्स

1
EXE की इकाई परीक्षण सामग्री में कुछ भी जटिल नहीं है। बस अपने परीक्षण DLL अपनी EXE फ़ाइल का संदर्भ लें, और आप जाने के लिए अच्छे हैं।
whatsisname

जवाबों:


3

मैंने अपनी एक टिप्पणी में सिमोरमैन के उत्तर का उल्लेख किया है कि मैंने ऐसा करने के कुछ तरीकों के बारे में सोचा था। मेरा एक विकल्प जालौन के उत्तर में डुप्लिकेट प्रोजेक्ट बनाने और डीएलएल उत्पन्न करने के सुझाव के समान था , जबकि मेरा अन्य विचार केवल उस प्रोजेक्ट की फाइलों से लिंक करना था जहां कोड था जिसे मैं परीक्षण करना चाहता था। जबकि दोनों विकल्पों को काम करने के लिए बनाया जा सकता है, वे आदर्श से कम हैं।

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

सबसे अच्छा तरीका ऐसा लगता है जैसे कि whatsisname ने मेरे प्रश्न पर टिप्पणी की, और EXE को परीक्षण परियोजना में एक संदर्भ के रूप में शामिल किया। यह पता चलता है कि एक EXE को इस मामले में DLL के समान प्रभावी ढंग से व्यवहार किया जाता है, और मैं अपनी नाव चलाने के लिए सभी अच्छी तरह से स्तरित कक्षाओं का उपयोग करने में सक्षम हूं।


2

मुझे लगता है कि:

  • आपका व्यवसाय परीक्षण कोड आपके व्यवसाय कोड पुस्तकालय का परीक्षण करने के लिए एक अलग परियोजना में होना चाहिए।
  • आपका GUI परीक्षण कोड आपके GUI लाइब्रेरी का परीक्षण करते हुए एक अलग प्रोजेक्ट में होना चाहिए। अब, निष्पादन योग्य के बजाय GUI पुस्तकालय का निर्माण कैसे करें, मैं बाद में उत्तर देने का प्रयास करता हूं।
  • यदि आपके पास my.namespace.biz.MyClass है, तो आपका परीक्षण वर्ग my.namespace.biz होना चाहिए। MyClassTest (या MyClassTestCase)।
  • यदि आप अपने निष्पादन योग्य लक्ष्य में पाए गए कोड का परीक्षण करना चाहते हैं, तो आपके पास एक सेटअप होना चाहिए जो एक EXE बनाता है, और एक अन्य सेटअप जो एक पुस्तकालय (DLL) का निर्माण करता है, जो कि आपके खिलाफ परीक्षण शुरू करेगा।

ये वे नियम हैं जिनका मैं पालन करना पसंद करता हूं, चाहे वह जावा हो या सी # (इसके अलावा जावा की कोई समस्या नहीं है;)

अपने परीक्षण वातावरण को कैसे कॉन्फ़िगर करें, यह मुझे लगता है कि आपके पास कम से कम ये दो विकल्प हैं:

MSBuild का उपयोग करना

अपनी .proj फ़ाइल का एक क्लोन बनाएं ( myproject-as-dll.proj )। OutputTypeक्लोन फाइल में " EXE" से " " में बदलें Library। MSBuild कमांड का उपयोग करके अब आप एक लाइब्रेरी का निर्माण कर सकते हैं जिसे आप अपने प्रोजेक्ट में संदर्भ के रूप में सेट कर सकते हैं जिसमें NUnit टेस्ट केस हैं।

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

NAnt का उपयोग करना

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

उस उपकरण के साथ आप एक कॉन्फ़िगरेशन के साथ आ सकते हैं जो आपको अनुमति देगा:

  • अपनी सभी परियोजनाओं (व्यावसायिक तर्क, जीयूआई, आदि) को अलग-अलग पुस्तकालयों में बनाएँ
  • अपने परीक्षण परियोजनाओं का निर्माण
  • परीक्षण शुरू करना (वह विशिष्ट भाग NUnit2 कार्य के साथ किया जाता है )।
  • NCover कार्य के साथ अपने कोड कवरेज की जाँच करें ।

अधिक कोड के साथ, आप भी कर सकते हैं:

  • अपने एकीकरण सर्वर में रात्रिकालीन तैनाती करें
  • यदि NAnt आपके एकीकरण सर्वर में उपलब्ध है, तो निर्धारित कार्यों की सहायता से रात्रि एकीकरण परीक्षण शुरू करें

सभी आपके Visual Studio फ़ाइलों में कुछ भी बदले बिना किया जाता है। और, वास्तव में, यह मुझे ओवर-इंजीनियरिंग की तरह नहीं दिखता है, यह सिर्फ एक फ़ाइल है। यह सब काम करने के लिए आपको एक, शायद दो दिन लग सकते हैं, लेकिन आप मेरी राय में एक अच्छा सेटअप लेंगे।

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


0

सिर्फ इसलिए कि प्रोजेक्ट छोटा है (शुरू में) इसका मतलब यह नहीं है कि उचित आर्किटेक्चर ओवर-इंजीनियरिंग है। तथ्य यह है कि आप परीक्षण लिखना चाहते हैं बताता है कि आपकी परियोजना पूरी तरह से एक-तरफ़ा हैक नहीं है।

आपने जो GUI- फ्रेमवर्क का उपयोग कर रहे हैं, उसका उल्लेख नहीं किया। डब्ल्यूपीएफ एमवीवीएम (मॉडल-व्यू-व्यूमॉडल) अच्छा है और आपको सभी लॉजिक के लिए काफी आसानी से परीक्षण लिखने की अनुमति देता है। WinForms के साथ मैंने MVP (मॉडल-व्यू-प्रस्तोता) के बारे में अच्छी बातें सुनी हैं


मैं उन सभी कोड के लिए परीक्षण लिखता हूं जो मैं लिखता हूं। यहां तक ​​कि सामान जो आपको मामूली मिल सकता है। केवल एक बार जब मैं एक परीक्षण नहीं लिखता हूं तो मैं स्पाइक करता हूं। इस मामले में, मैं एक ग्राहक को एक उपयोगिता बंद कर रहा हूं, इसलिए परीक्षण सिर्फ एक लक्जरी से अधिक है, यह हमारे गुणवत्ता मानकों को पूरा करने के लिए एक आवश्यकता है। "ओवर इंजीनियरिंग" के संदर्भ में, यह अच्छे या बुरे आर्किटेक्चर के बीच कोई विकल्प नहीं है, बल्कि अतिरिक्त लेयरिंग को लागू करने की आवश्यकता से बचना है जो इस उदाहरण में आवश्यक नहीं है क्योंकि ऐप अपेक्षाकृत कम जीवन चक्र के साथ एकल उद्देश्य है।
S.Robins

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

Simoraman - यदि आप पहले पैराग्राफ के बजाय निर्णय लिया है, यह एक जवाब की ओर हो रही होगी। इसे ठीक करें और मैं अपना -1 हटा दूंगा। @ S.Robins ध्यान दें कि दूसरा पैराग्राफ है प्रासंगिक - हालांकि नहीं एक पूरा जवाब है, यह मदद मिलेगी। यदि आपकी GUI परत पतली, अच्छी तरह से संरचित और स्पष्ट है, और सभी व्यावसायिक तर्क मॉडल स्तर पर इकाई परीक्षणों द्वारा जांचे जाते हैं, तो यह हो सकता है कि आपको UI को स्पष्ट रूप से परीक्षण करने की अतिरिक्त परेशानी से गुजरने की आवश्यकता न हो।
मार्क बूथ

1
@MarkBooth लेयरिंग वास्तव में एक समस्या नहीं है। जैसा कि सिमीरमन का उल्लेख है कि मैं एमवीपी, एमवीवीएम, या मैं भी पतले कुछ का निर्माण कर सकता हूं। हालांकि मेरे पास कुछ GUI विशिष्ट तत्व हैं जिन्हें स्पष्ट परीक्षण की आवश्यकता होगी, यही कारण है कि मैंने इसे एक प्रश्न के रूप में लिखने का फैसला किया। मेरे पास कुछ विचार हैं, और अगर इससे भी बदतर बात आती है तो मुझे पता है कि आखिरकार मैं समस्या को हल करने में सक्षम हो जाऊंगा और खुद ही जवाब लिखूंगा। हालाँकि मैं इसे समुदाय के लिए खोलना चाहता था क्योंकि मुझे लगा था कि यह प्रोग्रामर के लिए एक अच्छा सवाल होगा। ;-)
S.Robins

0

इस सवाल पर मेरे जवाब पर एक नज़र डालें: मैं Winforms समाधान के लिए MVP कैसे सेट करूं?

मैंने वास्तव में एक नमूना एप्लिकेशन लिखा है जो दिखाता है कि मैं कैसे परत करता हूं, और मैं कैसे परीक्षण करता हूं, मेरा जीयूआई।

अपना संपादन पढ़ना: एक परीक्षण धावक का उपयोग करें जो आपके विकास के वातावरण के साथ एकीकृत करता है। मैं ReSharper का उपयोग करता हूं।


ReSharper सिफारिश के लिए धन्यवाद। यह एक उपकरण है जिसे मैं विकसित करते समय उपयोग करता हूं। दुर्भाग्य से यह एकीकरण बिल्ड सर्वर पर परीक्षण निष्पादित करते समय मदद नहीं करेगा। यह मुझे यह भी नहीं बताता कि परीक्षण करते समय किसी एक्ज़िट में कोड तक पहुँचने के लिए ननिट परीक्षणों को कैसे कॉन्फ़िगर किया जाए।
रॉबिन्स

1
अनौपचारिक रूप से, यह करता है। Exe सिर्फ एक दृश्य है, जो प्रस्तुतकर्ता, मॉडल और viewmodels को एप्लिकेशन स्टार्टअप के हिस्से के रूप में एक क्लास लाइब्रेरी से लोड करता है। कम से कम मेरे समाधान में, दृश्य पर्याप्त गूंगा है कि हम इसे स्वचालित परीक्षणों के साथ परीक्षण नहीं करते हैं, और बस यह सुनिश्चित करने के लिए स्वीकृति परीक्षण करते हैं कि चीजें सही वर्तनी हैं और बटन वे हैं जहां उन्हें होना चाहिए। NUnit-dll का परीक्षण करना बहुत आसान है।
ब्रायन बोएचर

0

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


यदि आपका ग्राहक निर्दिष्ट करता है कि एक स्क्रीन को एक निश्चित तरीके से देखना चाहिए, या एक निश्चित तरीके से बदलना चाहिए, तो आपको इन चीजों के लिए परीक्षण करने में सक्षम होना चाहिए। परीक्षण के रूप में विशिष्टताओं को पकड़ना बीडीडी कार्यप्रणाली का दिल है, और मैंने कभी भी ऐसी स्थिति नहीं पाई है जहां आप रचनात्मक रूप से नहीं कर सकते - एक परीक्षण को स्वचालित करने का एक साधन खोजें। असली सवाल यह है कि क्या परीक्षण मूल्य का होगा, चाहे आवेदन आपको पहले से सभी परीक्षणों को स्वचालित करने की अनुमति देने के लिए पर्याप्त रूप से फैक्टर किया गया हो, और क्या परीक्षण लागत प्रभावी होंगे। मैं हालांकि सहमत हूं, कि कभी-कभी वे नहीं होते हैं।
S.Robins
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.