NUnit टेस्ट रन ऑर्डर

Question

डिफ़ॉल्ट रूप से ननिट परीक्षण वर्णानुक्रम में चलते हैं। क्या किसी को निष्पादन आदेश निर्धारित करने का कोई तरीका पता है? क्या इसके लिए एक विशेषता मौजूद है?

Comments

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

— रिचर्ड जूल

यह एक डुप्लिकेट की तरह दिखता है, लेकिन आप यहां पर

— जॉन्सन नोलन

@ रीचर्ड - चाहिए! = होना चाहिए। और यह वास्तव में एक घटना नहीं है, क्योंकि वास्तव में लगभग सभी एकीकरण परीक्षण क्रम में चलाए जाते हैं - यदि आप उनके परीक्षण के क्रम को यादृच्छिक करते हैं, तो आप क्यूए टीम से पूछें।

— tymtam

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

— मेल

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

— nrjohnstone

Answer 1

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

हालांकि ऐसे मौके हैं जहां आप पहले कुछ परीक्षण चलाना चाहेंगे। एक विशिष्ट उदाहरण एक निरंतर एकीकरण स्थिति में है जहां कुछ परीक्षण दूसरों की तुलना में लंबे समय तक चल रहे हैं। हम श्रेणी विशेषता का उपयोग करते हैं ताकि हम उन परीक्षणों को चला सकें जो डेटाबेस का उपयोग करने वाले परीक्षणों के आगे मॉकिंग का उपयोग करते हैं।

यानी इसे अपने त्वरित परीक्षणों की शुरुआत में रखें

[Category("QuickTests")]

जहां आपके पास परीक्षण हैं जो कुछ पर्यावरणीय परिस्थितियों पर निर्भर हैं, TestFixtureSetUp और TestFixtureTearDown विशेषताओं पर विचार करें , जो आपको अपने परीक्षणों से पहले और बाद में निष्पादित होने वाले तरीकों को चिह्नित करने की अनुमति देते हैं।

Comments

@ क्रिस, मैं इन विशेषताओं का उपयोग नहीं करता हूं, यह एक दिलचस्प ब्लॉग पोस्ट है- jamesnewkirk.typepad.com/posts/2007/09/why-you-should-.html । हालांकि श्रेणी परीक्षणों के बारे में अच्छी बात है।

— रिचर्ड जूल 3'09

ऑर्डर डिपेंडेंट टेस्ट का एक और उदाहरण है जब आप इंटीग्रेशन टेस्ट चलाने के लिए अपने ननिट फ्रेमवर्क का उपयोग करना चाहते हैं ...

— बायरन रॉस

@ByronRoss: जब मैं ऐसा करता हूं, तो मैं बड़े परीक्षण करता हूं, और मौजूदा इकाई परीक्षणों पर अधिक से अधिक झुक सकता हूं ताकि मैं कम परीक्षण लिख सकूं। फिर प्रत्येक पूर्ण रन अलग से विफल हो सकता है। मैं अपने डेटा को डिज़ाइन करने का प्रयास करता हूं ताकि यह मौजूदा डेटा के आधार पर अलग-अलग मौजूदा डेटा से अलग रह सके ।

— मेरलिन मॉर्गन-ग्राहम

यदि आप अपने परीक्षण यादृच्छिक क्रम में नहीं चलाते हैं, तो आप यह कैसे सत्यापित कर सकते हैं कि वे वास्तव में काम करते हैं? आप जो कह रहे हैं, वह यह कहने के अनुरूप है कि "यदि आपके सॉफ़्टवेयर में कोई बग नहीं है, तो परीक्षण अनैतिक है"।

— जेंबर्ग

@jforberg: यदि आपको कोई विफलता है जो अनियमित रूप से होती है, तो जब आप इसे ठीक कर लेते हैं तो आप कैसे कहते हैं?

— नीड हेक

Answer 2

मैं केवल यह बताना चाहता हूं कि जब अधिकांश उत्तरदाताओं ने मान लिया था कि ये यूनिट परीक्षण थे, तो सवाल यह नहीं था कि वे थे।

nUnit एक बेहतरीन उपकरण है जिसका उपयोग विभिन्न प्रकार की परीक्षण स्थितियों के लिए किया जा सकता है। मैं परीक्षण के आदेश को नियंत्रित करने के इच्छुक कारणों को देख सकता हूं।

उन स्थितियों में मुझे टेस्ट नाम में रन ऑर्डर शामिल करने का सहारा लेना पड़ा है। एक विशेषता का उपयोग करके रन ऑर्डर निर्दिष्ट करने में सक्षम होना बहुत अच्छा होगा।

Comments

आप मतलब है कि आप अपने परीक्षण, उदाहरण के लिए, 001_first_test 002_second_testऔर इतने पर बुलाया ?

— as999999

हां, यह सही है, हालांकि मैं आमतौर पर एक पैटर्न का उपयोग करता हूं जो मुझे आवश्यक होने पर आसानी से परीक्षण सम्मिलित करने की अनुमति देता है, इसलिए हो सकता है कि 010_first_test, 020_second_test, इत्यादि

— Les

यहाँ एकमात्र एकमात्र उत्तर के लिए धन्यवाद। यह एक विशिष्ट प्रश्न है, फिर भी किसी तरह अस्पष्ट अस्पष्ट उत्तर को उत्कीर्ण किया जा रहा है। हां, हम सभी जानते हैं कि यूनिट परीक्षण क्या होना चाहिए, हालांकि यह सवाल नहीं है।

— ईगोर पावलखिन

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

— हाबिल

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

— ब्रॉन डेविस

Answer 3

NUnit 3.2.0 ने एक जोड़ा OrderAttribute, देखें:

https://github.com/nunit/docs/wiki/Order-Attribute

उदाहरण:

public class MyFixture
{
    [Test, Order(1)]
    public void TestA() { ... }


    [Test, Order(2)]
    public void TestB() { ... }

    [Test]
    public void TestC() { ... }
}

Comments

थैंक्स, इस बात के लिए सही है कि मैं क्या देख रहा था - और कोई चर्चा नहीं, यह अच्छा या बुरा क्यों है :)

— aknoepfel

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

— इप्टा

आप हमेशा बहुत बड़ी संख्याओं जैसे लाखों या कुछ से शुरू कर सकते हैं यदि आप उस तरह से मध्य आइटम पेश करना चाहते हैं - बस अधिक टाइपिंग। Imo वहाँ एक आसान तरीका होना चाहिए एक विधि निर्भरता पेड़ की तरह प्राथमिकता के लिए उपयोग की संख्या से चीजों को ऑर्डर करने के लिए है, लेकिन प्रत्येक का अपना डिस / फ़ायदा है।

— रेज़वान फ्लेवियस पांडा

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

— ROX

दिलचस्प बात यह है कि मेरे अनुभव में, यदि हम टेस्ट और ऑर्डर विशेषताओं को अलग से जोड़ते हैं, तो परीक्षणों के आदेश की कोई गारंटी नहीं है।

— एटी

Answer 4

एक विशिष्ट क्रम में चलाने के लिए परीक्षणों को चाहने का मतलब यह नहीं है कि परीक्षण एक-दूसरे पर निर्भर हैं - मैं इस समय एक TDD प्रोजेक्ट पर काम कर रहा हूं, और एक अच्छा TDDer होने के नाते मैंने सब कुछ मॉकडाउन / स्टब किया है, लेकिन यह होगा यह अधिक पठनीय है यदि मैं उस आदेश को निर्दिष्ट कर सकता हूं जो परीक्षण के परिणाम प्रदर्शित किए जाते हैं - वर्णानुक्रम के बजाय। अब तक केवल एक चीज जो मैं सोच सकता हूं, वह है कक्षाओं, नेमस्पेस और विधियों के लिए कक्षाओं में a_ b_ c_ को प्रस्तुत करना। (अच्छा नहीं) मुझे लगता है कि एक [TestOrderAttribute] विशेषता अच्छी होगी - फ्रेमवर्क का सख्ती से पालन नहीं किया जाता है, लेकिन एक संकेत है ताकि हम इसे प्राप्त कर सकें

Answer 5

भले ही टेस्ट ऑर्डर पर निर्भर हो या न हो ... हममें से कुछ लोग एक व्यवस्थित अंदाज में सब कुछ कंट्रोल करना चाहते हैं।

यूनिट परीक्षण आमतौर पर जटिलता के क्रम में बनाए जाते हैं। तो, उन्हें भी जटिलता के क्रम में क्यों नहीं चलाया जाना चाहिए, या वे जिस क्रम में बनाए गए हैं?

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

लेकिन, मैं उन्हें यादृच्छिक क्रम में चलाने का लाभ भी देख सकता हूं, खासकर यदि आप यह परीक्षण करना चाहते हैं कि आपके परीक्षणों का अन्य परीक्षणों पर कोई निर्भरता नहीं है। रनर्स को "रन टेस्ट रेंडमली स्टॉप तक" टेस्ट करने के लिए एक विकल्प जोड़ने के बारे में कैसे?

Answer 6

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

इसलिए, मैंने उन्हें क्रम में रखा और पाठ बक्से और इस तरह के पूर्ण होने के लिए पिछले परीक्षणों पर निर्भर रहा। मैं Assert.Ignore () का उपयोग करता हूं, जब पूर्व शर्तें मान्य नहीं हैं, लेकिन मुझे उन्हें क्रम में चलाने की आवश्यकता है।

Comments

पूरी तरह से। मैं यहाँ एक ही नाव में हूँ।

— स्लीपर स्मिथ

मैं भी! बिल्कुल मैं इस सवाल पर क्यों उतरा!

— निकल्स वुल्फ

यदि आप दृश्य स्टूडियो का उपयोग ननिट, डंप ननिट और एमएस परीक्षणों का उपयोग कर रहे हैं तो @NiklasRingdahl। तब आप दृश्य स्टूडियो की फ़ाइल का उपयोग कर सकते हैं ताकि आप उन्हें निष्पादित किए जाने के क्रम में परीक्षण मामलों की व्यवस्था कर सकें

— राहुल लोढ़ा

@RahulLodha धन्यवाद! मुझे इस पर गौर करना होगा।

— निकलेस वुल्फ

Answer 7

मुझे वास्तव में पिछला उत्तर पसंद है।

मैंने ऑर्डर रेंज सेट करने के लिए एक विशेषता का उपयोग करने में सक्षम होने के लिए इसे थोड़ा बदल दिया:

namespace SmiMobile.Web.Selenium.Tests
{
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Reflection;
    using NUnit.Framework;

    public class OrderedTestAttribute : Attribute
    {
        public int Order { get; set; }


        public OrderedTestAttribute(int order)
        {
            Order = order;
        }
    }

    public class TestStructure
    {
        public Action Test;
    }

    class Int
    {
        public int I;
    }

    [TestFixture]
    public class ControllingTestOrder
    {
        private static readonly Int MyInt = new Int();

        [TestFixtureSetUp]
        public void SetUp()
        {
            MyInt.I = 0;
        }

        [OrderedTest(0)]
        public void Test0()
        {
            Console.WriteLine("This is test zero");
            Assert.That(MyInt.I, Is.EqualTo(0));
        }

        [OrderedTest(2)]
        public void ATest0()
        {
            Console.WriteLine("This is test two");
            MyInt.I++; Assert.That(MyInt.I, Is.EqualTo(2));
        }


        [OrderedTest(1)]
        public void BTest0()
        {
            Console.WriteLine("This is test one");
            MyInt.I++; Assert.That(MyInt.I, Is.EqualTo(1));
        }

        [OrderedTest(3)]
        public void AAA()
        {
            Console.WriteLine("This is test three");
            MyInt.I++; Assert.That(MyInt.I, Is.EqualTo(3));
        }


        [TestCaseSource(sourceName: "TestSource")]
        public void MyTest(TestStructure test)
        {
            test.Test();
        }

        public IEnumerable<TestCaseData> TestSource
        {
            get
            {
                var assembly =Assembly.GetExecutingAssembly();
                Dictionary<int, List<MethodInfo>> methods = assembly
                    .GetTypes()
                    .SelectMany(x => x.GetMethods())
                    .Where(y => y.GetCustomAttributes().OfType<OrderedTestAttribute>().Any())
                    .GroupBy(z => z.GetCustomAttribute<OrderedTestAttribute>().Order)
                    .ToDictionary(gdc => gdc.Key, gdc => gdc.ToList());

                foreach (var order in methods.Keys.OrderBy(x => x))
                {
                    foreach (var methodInfo in methods[order])
                    {
                        MethodInfo info = methodInfo;
                        yield return new TestCaseData(
                            new TestStructure
                                {
                                    Test = () =>
                                        {
                                            object classInstance = Activator.CreateInstance(info.DeclaringType, null);
                                            info.Invoke(classInstance, null);
                                        }
                                }).SetName(methodInfo.Name);
                    }
                }

            }
        }
    }
}

Comments

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

— क्रिसपी

OrderedTestNUnit 3 में अब समर्थित नहीं है

— कॉनराड

Answer 8

मुझे पता है कि यह एक अपेक्षाकृत पुरानी पोस्ट है, लेकिन यहां परीक्षण के नामों को अजीब बनाने के बिना अपना परीक्षण रखने का एक और तरीका है। TestCaseSource विशेषता का उपयोग करके और जिस ऑब्जेक्ट को आप किसी प्रतिनिधि (क्रिया) में पास करते हैं, उसका उपयोग करके, आप न केवल आदेश को नियंत्रित कर सकते हैं, बल्कि परीक्षण को नाम भी दे सकते हैं कि यह क्या है।

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

यहाँ एक प्रस्तुति से एक डेमो है जो मैं कल दे रहा हूँ:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using NUnit.Framework;

namespace NUnitTest
{
    public class TestStructure
    {
        public Action Test;
    }

    class Int
    {
        public int I;
    }

    [TestFixture]
    public class ControllingTestOrder
    {
        private static readonly Int MyInt= new Int();

        [TestFixtureSetUp]
        public void SetUp()
        {
            MyInt.I = 0;
        }

        [TestCaseSource(sourceName: "TestSource")]
        public void MyTest(TestStructure test)
        {
            test.Test();
        }

        public IEnumerable<TestCaseData> TestSource
        {
            get
            {
                yield return new TestCaseData(
                    new TestStructure
                    {
                        Test = () =>
                        {
                            Console.WriteLine("This is test one");
                            MyInt.I++; Assert.That(MyInt.I, Is.EqualTo(1));
                        }
                    }).SetName(@"Test One");
                yield return new TestCaseData(
                    new TestStructure
                    {
                        Test = () =>
                        {
                            Console.WriteLine("This is test two");
                            MyInt.I++; Assert.That(MyInt.I, Is.EqualTo(2));
                        }
                    }).SetName(@"Test Two");
                yield return new TestCaseData(
                    new TestStructure
                    {
                        Test = () =>
                        {
                            Console.WriteLine("This is test three");
                            MyInt.I++; Assert.That(MyInt.I, Is.EqualTo(3));
                        }
                    }).SetName(@"Test Three");
            }
        }
    }
}

Comments

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

— नवतपा

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

— क्रिसपी

अफसोस की बात है, NUnit 3 के साथ, स्रोत का TestCaseSourceस्थिर होना आवश्यक है, जो पैटर्न का उपयोग करने से रोकता है। ओह।

— कोनराड

@Conrad। मैं यह नहीं देखता कि विधि को स्थिर बनाने या न करने से क्या फर्क पड़ता है। परीक्षण अभी भी किसी भी तरह से वापस आता है।

— डेव बुश

यह वह विधि नहीं है जिसे स्थिर होने की आवश्यकता है - स्रोत (चर या संपत्ति) TestCaseSourceNUnit 3 में एक स्थिर वस्तु होनी चाहिए, या परीक्षण निष्पादित नहीं होंगे। और आप एक स्थिर वस्तु के भीतर गतिशील वस्तुओं का निर्माण नहीं कर सकते। इसलिए यह v में काम नहीं करेगा। 3.

— कोनराड

Answer 9

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

ये यूआई परीक्षण निश्चित रूप से निष्पादन के आदेश पर निर्भर करते हैं, क्योंकि अन्य परीक्षण में एक पूर्व शर्त के रूप में कुछ डेटा जोड़ने की आवश्यकता होती है। (हर परीक्षा में कदम उठाना संभव नहीं है)

अब, 10 वीं परीक्षा के मामले को जोड़ने के बाद, मैं देखता हूं कि Nnnit इस क्रम में चलना चाहता है: Test_1 Test_10 Test_2___

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

Comments

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

— ज़सज़

Answer 10

आमतौर पर यूनिट टेस्ट स्वतंत्र होना चाहिए, लेकिन अगर आपको होना चाहिए, तो आप अपने तरीकों को वर्णमाला क्रम में पूर्व नाम दे सकते हैं:

[Test]
public void Add_Users(){}

[Test]
public void Add_UsersB(){}

[Test]
public void Process_Users(){}

या आप कर सकते हैं ..

        private void Add_Users(){}

        private void Add_UsersB(){}

        [Test]
        public void Process_Users()
        {
           Add_Users();
           Add_UsersB();
           // more code
        }

Comments

सिवाय अब नामों को वर्णमाला बनाया जाना चाहिए, जो एक भयानक समाधान है। :(

@ user166390 - नहीं यह भयानक नहीं है। यह काम करता है और NUnit के प्रलेखित व्यवहार पर निर्भर करता है।

— tymtam

➕1 मेरे लिए काफी अच्छा है, यदि आप अपने परीक्षणों की शुरुआत करते हैं, तो बहुत आसान है a_ b_ t1_, t2_बजाय इसके या अनुगामी पात्रों को याद करने के लिए आसान पर भरोसा करना

— क्रिस मैरिकिक

Answer 11

टेस्ट ऑर्डरिंग तंत्र का उपयोग करने के बहुत अच्छे कारण हैं। मेरे स्वयं के अधिकांश परीक्षण सेटअप / अशांति जैसे अच्छे अभ्यास का उपयोग करते हैं। दूसरों को भारी मात्रा में डेटा सेटअप की आवश्यकता होती है, जिसका उपयोग कई प्रकार की विशेषताओं का परीक्षण करने के लिए किया जा सकता है। अब तक, मैंने इन (सेलेनियम वेबड्राइवर) एकीकरण परीक्षणों को संभालने के लिए बड़े परीक्षणों का उपयोग किया है। हालाँकि, मुझे लगता है कि उपरोक्त सुझाव पोस्ट https://github.com/nunit/docs/wiki/Order-Attribute में बहुत योग्यता है। यहाँ इस बात का उदाहरण दिया गया है कि ऑर्डर करना कितना मूल्यवान होगा:

• रिपोर्ट डाउनलोड करने के लिए परीक्षण चलाने के लिए सेलेनियम वेबड्राइवर का उपयोग करना
• रिपोर्ट की स्थिति (यह डाउनलोड करने योग्य है या नहीं) 10 मिनट के लिए कैश की जाती है
• इसका मतलब है, प्रत्येक परीक्षण से पहले मुझे रिपोर्ट स्थिति को रीसेट करना होगा और फिर 10 मिनट तक इंतजार करना होगा राज्य की पुष्टि होने से पहले , और फिर रिपोर्ट डाउनलोड को सही तरीके से सत्यापित करें।
• रिपोर्ट को उनकी जटिलता के कारण परीक्षण ढांचे के भीतर नकली या किसी अन्य तंत्र के माध्यम से एक व्यावहारिक / समय पर फैशन में उत्पन्न नहीं किया जा सकता है।

यह 10 मिनट प्रतीक्षा समय परीक्षण सूट को धीमा कर देता है। जब आप परीक्षण की एक भीड़ में समान कैशिंग विलंब को गुणा करते हैं, तो इसमें बहुत समय लगता है। ऑर्डर करने वाले परीक्षण डेटा सेटअप को परीक्षण सूट की शुरुआत में "टेस्ट" के रूप में सही तरीके से करने की अनुमति दे सकते हैं, परीक्षण के अंत तक निष्पादित होने के लिए कैश पर भरोसा करने के लिए परीक्षण पर भरोसा करते हैं।

Answer 12

यह प्रश्न वास्तव में अब पुराना है, लेकिन जो लोग खोज से इस तक पहुंच सकते हैं, मैंने user3275462 और PvtVandals / Rico से उत्कृष्ट उत्तर लिए और उन्हें अपने कुछ अपडेट के साथ GitHub रिपॉजिटरी में जोड़ा । मैंने कुछ अतिरिक्त जानकारी के साथ एक संबद्ध ब्लॉग पोस्ट भी बनाई है जिसे आप अधिक जानकारी के लिए देख सकते हैं।

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

Comments

क्या आप मेरी मदद कर सकते हैं मेरे पास एक मुद्दा है, यहाँ लिंक है: stackoverflow.com/questions/31281395/…

— मॉर्गन सोरेन

Answer 13

मैं NUnit समुदाय से कुछ भी करने के लिए तैयार नहीं हूं, इसलिए मैं खुद इस तरह का कुछ बनाने गया था।

मैं वर्तमान में एक ओपन-सोर्स लाइब्रेरी विकसित कर रहा हूं जो आपको NUnit के साथ अपने परीक्षण का आदेश दे सकती है। आप परीक्षण जुड़नार और "ऑर्डर किए गए परीक्षण विनिर्देशों" को समान रूप से ऑर्डर कर सकते हैं।

पुस्तकालय निम्नलिखित विशेषताएं प्रदान करता है:

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

लाइब्रेरी वास्तव में प्रेरित है कि कैसे MSTest .orderedtestफाइलों के साथ परीक्षण के आदेश देता है। कृपया नीचे एक उदाहरण देखें।

[OrderedTestFixture]
public sealed class MyOrderedTestFixture : TestOrderingSpecification {
    protected override void DefineTestOrdering() {
        TestFixture<Fixture1>();

        OrderedTestSpecification<MyOtherOrderedTestFixture>();

        TestFixture<Fixture2>();
        TestFixture<Fixture3>();
    }

    protected override bool ContinueOnError => false; // Or true, if you want to continue even if a child test fails
}

Answer 14

यदि आप उपयोग कर रहे हैं [TestCase], तो तर्क TestNameपरीक्षण के लिए एक नाम प्रदान करता है।

यदि निर्दिष्ट नहीं है, तो एक नाम विधि के नाम और प्रदान किए गए तर्कों के आधार पर उत्पन्न होता है।

आप नीचे दिए गए अनुसार परीक्षण निष्पादन के क्रम को नियंत्रित कर सकते हैं:

                    [Test]
            [TestCase("value1", TestName = "ExpressionTest_1")]
            [TestCase("value2", TestName = "ExpressionTest_2")]
            [TestCase("value3", TestName = "ExpressionTest_3")]
            public void ExpressionTest(string  v)
            {
                //do your stuff
            }

यहाँ मैंने "ExpressionTest"एक संख्या के साथ विधि नाम प्रत्यय का उपयोग किया है ।

आप वर्णमाला देखने के लिए किसी भी नाम का उपयोग कर सकते हैं TestCase विशेषता को देखें

Answer 15

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

मैंने थोड़ी गुगली की। हमेशा की तरह, कुछ लोगों ने डराने वाली चालों का सहारा लिया है (बजाय अंतर्निहित परीक्षण क्षमता / डिजाइन मुद्दे को हल करने के

• परीक्षणों को वर्णानुक्रम में क्रमबद्ध तरीके से नामित करना ताकि परीक्षण उस क्रम में दिखाई दें, जिसे वे निष्पादित करना चाहते हैं। हालाँकि NUnit इस व्यवहार को बाद में जारी करने के साथ बदलने का विकल्प चुन सकता है और फिर आपके परीक्षण रद्द कर दिए जाएंगे। स्रोत नियंत्रण के लिए वर्तमान NUnit बायनेरिज़ में बेहतर जाँच करें।
• वीएस (आईएमएचओ अपने 'चुस्त औजारों' के साथ गलत व्यवहार को प्रोत्साहित करने वाले) को उनके एमएस परीक्षण ढांचे में "ऑर्डर किए गए परीक्षण" के रूप में कहा जाता है। मैंने पढ़ने में कोई समय बर्बाद नहीं किया, लेकिन यह उसी दर्शकों के लिए लक्षित किया जा रहा है

यह भी देखें: एक अच्छे परीक्षण की विशेषताएं

Comments

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

— मार्सेल वाल्डेज़ ओरोज़्को

@MarcelValdezOrozco - आप विभिन्न भौतिक dll के माध्यम से या टैग / श्रेणियों का उपयोग करके अपने परीक्षणों को विभाजित करके उस लक्ष्य को प्राप्त कर सकते हैं। आप क्रम में dll / श्रेणियां चलाने के लिए अपनी बिल्ड स्क्रिप्ट बना सकते हैं। सामान्य तौर पर, परीक्षणों के आदेश देने की अनुमति आमतौर पर युग्मित परीक्षणों की ओर जाती है जो पड़ोसी परीक्षणों (निश्चित रूप से समय के साथ) पर निर्भरता विकसित करते हैं। NUnit की अगली बड़ी रिलीज में AFAIR, यह परीक्षण के विभिन्न आदेशों का समर्थन करने जा रहा है, जैसे यादृच्छिक आदि

— Gishu

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

— मार्सेल वाल्डेज़ ओरोज्को

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

— केली एल्टन

यह काफी संरक्षणात्मक उत्तर है और यह इसे मज़ेदार बनाता है क्योंकि यह वास्तव में केवल यूनिट परीक्षणों पर लागू होता है और पूरी तरह से व्यावहारिक होने की उपेक्षा करता है।

— tymtam

Answer 16

TestCaseSourceकुंजी का उपयोग करने के मामले में override string ToString, यह कैसे काम करता है:

मान लें कि आपके पास TestCase क्लास है

public class TestCase
{
    public string Name { get; set; }
    public int Input { get; set; }
    public int Expected { get; set; }
}

और टेस्टकेस की सूची:

private static IEnumerable<TestCase> TestSource()
{
    return new List<TestCase>
    {
        new TestCase()
        {
           Name = "Test 1",
           Input = 2,
           Expected = 4
        },
        new TestCase()
        {
            Name = "Test 2",
            Input = 4,
            Expected = 16
        },
        new TestCase()
        {
            Name = "Test 3",
            Input = 10,
            Expected = 100
        }
    };
}

अब इसे एक टेस्ट विधि के साथ उपयोग करें और देखें कि क्या होता है:

[TestCaseSource(nameof(TestSource))]
public void MethodXTest(TestCase testCase)
{
    var x = Power(testCase.Input);
    x.ShouldBe(testCase.Expected);
}

यह क्रम में परीक्षण नहीं करेगा और आउटपुट इस तरह होगा:

इसलिए अगर हम override string ToStringअपनी कक्षा में शामिल होते हैं जैसे:

public class TestCase
{
    public string Name { get; set; }
    public int Input { get; set; }
    public int Expected { get; set; }

    public override string ToString()
    {
        return Name;
    }
}

परिणाम बदल जाएगा और हमें परीक्षण का क्रम और नाम मिलेगा:

ध्यान दें:

1. यह केवल उदाहरण के लिए है कि परीक्षण में नाम और आदेश कैसे प्राप्त करें, यह आदेश संख्यात्मक रूप से / वर्णानुक्रम में लिया जाता है, इसलिए यदि आपके पास दस से अधिक परीक्षण हैं, तो मैं टेस्ट 01, टेस्ट 02 बनाने का सुझाव देता हूं। टेस्ट 10, टेस्ट 11 आदि क्योंकि आप टेस्ट 1 बनाते हैं और कुछ बिंदु पर टेस्ट 10 ऑर्डर से टेस्ट 1, टेस्ट 10, टेस्ट 2 .. आदि होगा।
2. इनपुट और प्रत्याशित किसी भी प्रकार, स्ट्रिंग, ऑब्जेक्ट या कस्टम वर्ग हो सकता है।
3. आदेश के अलावा, अच्छी बात यह है कि आप परीक्षण नाम देखते हैं जो अधिक महत्वपूर्ण है।