Autofixture: NCrunch और AutoFixture एकीकरण मुद्दे

नमस्ते, मैं एनक्रंच का डेवलपर हूं।

इसका समाधान खोजने के लिए आपके साथ काम करने में मुझे खुशी होगी। वर्तमान डिजाइन के साथ, मैं केवल एकीकरण बिंदु के अपने पक्ष में समस्या को हल करने के विकल्पों से दुखी हूं। मेरा मानना ​​​​है कि मेरा धावक संभवतः अकेला नहीं है जिसने वर्तमान डिजाइन के साथ समस्याओं का अनुभव किया है।

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

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

@remcomulder यहां भाग लेने के लिए आपका बहुत-बहुत धन्यवाद - अत्यधिक सराहना! मैंने इसकी थोड़ी जांच की है और अपने निष्कर्ष साझा करना चाहूंगा। मेरे सभी निष्कर्ष केवल xUnit पर लागू होते हैं।

TL DR: xUnit ऐसे सिद्धांतों का समर्थन करता है और NCrunch को xUnit के लिए भी उनका समर्थन करना चाहिए। एनयूनीट के लिए - यह एक खुला प्रश्न है और मैंने अभी तक इसकी जांच नहीं की है।

हमारे द्वारा उपयोग की जाने वाली सुविधा xUnit के लिए _legal_ प्रतीत होती है। हमारे पास अपना खुद का TestDataDiscoverer है जो इंगित करता है कि हमारे सिद्धांतों को पूर्व-खोज नहीं किया जा सकता है (क्योंकि हम यादृच्छिक डेटा उत्पन्न करते हैं)। बाद में हम इस खोजकर्ता के साथ अपने इस विशेषता का सम्मान करता है और खोज के दौरान पैरामीटर मानों को हल नहीं करता है।

मेरा मानना ​​​​है कि मेरा धावक संभवतः अकेला नहीं है जिसने वर्तमान डिजाइन के साथ समस्याओं का अनुभव किया है।

दरअसल, यह सच नहीं है और ऐसे सिद्धांतों के साथ R# और VS दोनों ठीक काम करते हैं। वे विशेष सिद्धांत को फिर से चलाने की अनुमति भी देते हैं, भले ही इसमें ऑटो-जेनरेटेड डेटा हो। मैं वीएस पर ध्यान केंद्रित करने का सुझाव दूंगा क्योंकि इसमें खोज और रन चरण भी शामिल हैं और यह ओपन-सोर्स है।

निम्नलिखित परीक्षण कोड पर विचार करें:

using Ploeh.AutoFixture.Xunit2;
using Xunit;

namespace Playground
{
    public class UnitTest
    {
        [Fact]
        public void StableTest()
        {
            Assert.True(true);
        }

        [Theory]
        [InlineData(1)]
        public void StableInlineTest(int value)
        {
            Assert.Equal(1, value);
        }

        [Theory, AutoData]
        public void VolatileTest(int value)
        {
            Assert.True(value % 2 == 0);
        }

        [Theory]
        [InlineAutoData(10)]
        [InlineAutoData(20)]
        [InlineAutoData(30)]
        public void VolatileTestWithInline(int value, int autoValue)
        {
            Assert.NotEqual(value, 40);
        }
    }
}

.NET Framework परीक्षण पुस्तकालय परियोजना। वीएस 2017.3। लक्ष्य ढांचा: 4.5.2। स्थापित पैकेज:

• xunit 2.2.0
• xunit.runner.visualstudio 2.2.0
• AutoFixture 3.50.6
• AutoFixture.Xunit2 3.50.6

यदि आप वीएस में खोज को ट्रिगर करते हैं, तो आप निम्न आउटपुट देखेंगे:

जैसा कि आप देख सकते हैं, डेटा खोज ( StableInlineTest ) का समर्थन करने वाले सिद्धांतों के लिए, वीएस रनर वास्तविक डेटा दिखाता है जिसके साथ परीक्षण चलाया जाएगा ( 1 )। उन परीक्षणों के लिए जो डेटा खोज का समर्थन नहीं करते हैं और जिनमें ऑटो-जेनरेटेड डेटा शामिल है ( VolatileTest , VolatileTestWithInline ) VS थ्योरी मामलों की खोज नहीं करता है और आपको केवल संपूर्ण सिद्धांत दिखाता है। आपके दौड़ने के बाद ही, आप इस विशेष आह्वान के लिए मान देख पाएंगे:

अब आप विशेष सिद्धांत को फिर से चला सकते हैं और यह _सभी सिद्धांत मामलों_ को फिर से चलाएगा।

जैसा कि आप देख सकते हैं, वास्तव में ऐसे सिद्धांतों का समर्थन करने का एक तरीका है और xUnit इसे पूरी तरह से करता है। एनक्रंच को इस तथ्य को ध्यान में रखना चाहिए कि कुछ सैद्धांतिक मामलों की पूर्व-खोज नहीं की जा सकती है। ऐसे सिद्धांतों के लिए आपको किसी विशेष मामले के बजाय पूरे सिद्धांत को फिर से चलाने की जरूरत है। मैं नहीं देखता कि ऐसा क्यों संभव नहीं है।

इस मुद्दे को हल करने का एकमात्र विश्वसनीय तरीका यह होगा कि परीक्षण मापदंडों की सभी यादृच्छिक पीढ़ी को हटा दिया जाए और इसके बजाय निश्चित मानों (यानी प्लेसहोल्डर या कॉन्स्ट) का उपयोग किया जाए।

वर्तमान में xUnit प्रदर्शन नाम बदलने और जनरेट किए गए डेटा को प्लेसहोल्डर्स से बदलने के लिए API को प्रदर्शित नहीं करता है। मैंने उनके लिए एक मुद्दा बनाया है ( यहां देखें), हालांकि ब्रैड का जवाब है कि यह असत्य है और वे केवल उस खोज को अक्षम करने का सुझाव देते हैं, जो हम पहले से ही कर रहे हैं।

या अन्यथा पैरामीटर मानों की सीडिंग को परीक्षण मामले में ही सीमित करें।

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

सदस्य डेटा

प्रलेखन में यहां आपके पास एक और नमूना है (मैंने इसे XUnit पर फिर से लिखा है):

public class MemberDataSample
{
    public IEnumerable<object[]> GetData()
    {
        yield return new object[]
        {
            DateTime.Now
        };
    }

    [Theory, MemberData(nameof(GetData), DisableDiscoveryEnumeration = true)]
    public void DateTheory(DateTime dt)
    {
        Assert.True(DateTime.Now - dt < TimeSpan.FromMinutes(1));
    }
}

यह xUnit के लिए बिल्कुल कानूनी है क्योंकि इसमें DisableDiscoveryEnumeration विशेषता है। यह ऊपर के नमूने की तरह काम करता है - सिद्धांत के मामलों की पूर्व-खोज नहीं की जा रही है।

तल - रेखा

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

यह देखते हुए कि आर # और वीएस दोनों ऐसे सिद्धांतों का समर्थन करते हैं, इससे मुझे लगता है कि वास्तव में हमारे उत्पाद के साथ सब कुछ सही है ..

जहां तक ​​NUnit का सवाल है - आइए उस पर चर्चा करें क्योंकि मैंने अभी तक इसकी जांच नहीं की है। शायद, हमारे पास इसके लिए ऐसा कोई एपीआई नहीं है।

क्या आप कृपया मेरे निष्कर्षों को देखते हुए xUnit समर्थन के बारे में अपनी राय साझा कर सकते हैं? क्या आप इसके लिए समर्थन जोड़ेंगे
xUnit (सभी परीक्षणों को फिर से चलाना बंद करें) और उस असंगति चेतावनी को दिखाने के लिए रुकें? मैं

ऐसा लगता है कि मैं यहां आपसे माफी मांग सकता हूं। आपके द्वारा बताए गए कारणों से, आपके द्वारा ऊपर वर्णित उपयोग केस एनसीआरंच के तहत सही ढंग से काम करता है। Xunit सिद्धांत की पूर्व-गणना से बच रहा है और इसे एक एकल परीक्षण में ढहा रहा है जहां इसे सुरक्षित रूप से पहचाना और निष्पादित किया जाता है। अब इसका परीक्षण करने पर, मैं पुष्टि कर सकता हूं कि एनक्रंच इसे सही तरीके से करता है। ऐसा लगता है कि हमें InlineAutoData के साथ कोई स्पष्ट समस्या नहीं है।

मुझे यकीन नहीं है कि यह मेरे लिए पहले क्यों विफल रहा। मैं वर्तमान में खुद को ऐसा परिदृश्य बनाने में असमर्थ हूं जिसमें यह विफल हो जाए। मुझे पता है कि मेरे पास उपयोगकर्ताओं ने मुझे बताया है कि InlineAutoData काम नहीं कर रहा था, हालांकि मुझे लगता है कि उन्हें आगे आना होगा और उदाहरण देना होगा कि यह कहां है।

मैं आपका ध्यान एक विशिष्ट उपयोग के मामले की ओर आकर्षित करना चाहता हूं जो मुझे पता है कि एनक्रंच और वीएस रनर दोनों को तोड़ देगा। मुझे लगता है कि यह ReSharper और TD.NET को भी तोड़ देगा, हालाँकि मैंने इनका परीक्षण नहीं किया है क्योंकि मैंने इन्हें स्थापित नहीं किया है:

using Ploeh.AutoFixture;
using Ploeh.AutoFixture.Xunit2;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Xunit;

namespace XUnitAutoFixture
{
    public class TestFixture
    {
        private static readonly Fixture Fixture = new Fixture();

        public static IEnumerable<object[]> SomeTestData()
        {
            yield return new object[] { Fixture.Create<string>() };
            yield return new object[] { Fixture.Create<string>() };
        }

        [Theory, MemberData(nameof(SomeTestData))]
        public void Test(object value)
        {

        }
    }
}

उपरोक्त कोड सभी चयनात्मक निष्पादन परिदृश्यों के तहत विफल हो जाएगा। हालाँकि, यदि परीक्षण एक ही चरण में खोजे और निष्पादित किए जाते हैं, तो यह पास हो जाएगा। ऑटोफिक्चर के बारे में एनक्रंच द्वारा दी जा रही चेतावनी के पीछे यह परिदृश्य उत्प्रेरक था, क्योंकि उपयोगकर्ता ऐसा कर रहे थे और समर्थन मांग रहे थे। यह देखते हुए कि मुझे पूर्व-गणना अक्षम करने वाले AutoFixture के बारे में नहीं पता था, मैंने मान लिया था (गलत तरीके से) कि InlineAutoData वही था।

मेरी वर्तमान धारणा यह है कि आप ऐसे परिदृश्य का समर्थन नहीं करते हैं। क्या यह सही है?

अब इसका परीक्षण करने पर, मैं पुष्टि कर सकता हूं कि एनक्रंच इसे सही तरीके से करता है।

एक दम बढ़िया! यह जानकर खुशी हुई कि वास्तव में xUnit पूरी तरह से NCrunch द्वारा समर्थित है जहां तक ​​NUnit का सवाल है - यह हमेशा से ही अनाड़ी रहा है और हमें इसकी जांच करने की आवश्यकता है कि हम वहां क्या कर सकते हैं।

हालाँकि, मैं अभी भी NCrunch और AutoFixture के साथ समस्याओं का निरीक्षण करता हूँ। वर्तमान में मेरे पास ऑटोफिक्चर के साथ xUnit प्रोजेक्ट है और यदि मैं एक भी लाइन बदलता हूं, तो सभी परीक्षण फिर से चलाए जाते हैं। ऐसा लगता है कि जब आप ऑटोफिक्चर का पता लगाते हैं तो आप इस तरह के व्यवहार को सक्षम करते हैं ताकि यह सुनिश्चित हो सके कि कुछ भी छूटा नहीं है।

ऐसा क्या? यदि हां, तो क्या आप इसे ठीक कर सकते हैं ताकि xUnit के लिए इस तरह के व्यवहार को अक्षम किया जा सके क्योंकि वहां सब कुछ ठीक है?

मैं आपका ध्यान एक विशिष्ट उपयोग के मामले की ओर आकर्षित करना चाहता हूं जो मुझे पता है कि एनक्रंच और वीएस रनर दोनों को तोड़ देगा।
मेरी वर्तमान धारणा यह है कि आप ऐसे परिदृश्य का समर्थन नहीं करते हैं। क्या यह सही है?

हां, वह परिदृश्य सभी धावकों को तोड़ देगा। हालाँकि, जैसा कि आपके फ़ोरम पर कहीं सही ढंग से इंगित किया गया था, यह AutoFixture के कारण नहीं है, क्योंकि आप ऐसा कुछ लिख सकते हैं जो काम नहीं करेगा:

public class TestFixture
{
    public static IEnumerable<object[]> SomeTestData()
    {
        yield return new object[] { DateTime.Now.Ticks };
        yield return new object[] { DateTime.Now.Ticks };
    }

    [Theory, MemberData(nameof(SomeTestData))]
    public void Test(object value)
    {

    }
}

ऐसे परिदृश्य के लिए यह आपकी जिम्मेदारी है कि आप पूर्व-खोज को मैन्युअल रूप से अक्षम करें, ताकि यह इस तरह दिखे ( DisableDiscoveryEnumeration संपत्ति पर ध्यान दें):

public class TestFixture
{
    private static readonly Fixture Fixture = new Fixture();

    public static IEnumerable<object[]> SomeTestData()
    {
        yield return new object[] { Fixture.Create<string>() };
        yield return new object[] { Fixture.Create<string>() };
    }

    [Theory, MemberData(nameof(SomeTestData), DisableDiscoveryEnumeration = true)]
    public void Test(object value)
    {

    }
}

वास्तव में, यह बहुत ही दुर्लभ परिदृश्य माना जाता है क्योंकि हमारे पास डेटा निर्माण के लिए AutoData और InlineAutoData विशेषताएँ हैं। इसके अलावा AutoFixture केवल एक उपकरण है और इसे सही तरीके से उपयोग करने के लिए डेवलपर की जिम्मेदारी है।

मैं NCrunch को एक विशेष मोड में केवल इसलिए नहीं ले जाऊँगा क्योंकि ऐसे लोग हैं जो गलत तरीके से टूल का उपयोग कर सकते हैं। सबसे अच्छा हम यहां यह कर सकते हैं कि इस विशेष परिदृश्य का वर्णन करने के लिए कहीं न कहीं एक ज्ञात समस्या डालें और लोगों से xUnit का ठीक से उपयोग करने के लिए कहें (क्योंकि वे इसके बारे में नहीं जानते होंगे)।

क्या आप कृपया पुष्टि कर सकते हैं कि यदि आप AutoFixture का पता लगाते हैं तो आप एक विशेष तरीके से परीक्षण चलाते हैं और यदि ऐसा है, तो क्या आप कृपया उस मोड को xUnit के लिए अक्षम कर सकते हैं (NUnit के लिए इसे वैसे ही रखना बेहतर है)। यह भी संभावना है कि इस पृष्ठ को भी अद्यतन किया जाना चाहिए।

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

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

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

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

कोई चिंता नहीं! यह बिल्कुल ठीक है और हम सब यहां एक-दूसरे को चीजों को समझने में मदद करने के लिए हैं 😅 यह बहुत अच्छा है कि आपने टिकट का अनुसरण किया और हमने उस पर चर्चा की - यह बहुत अधिक है

मैंने आपसे जो सीखा है, उसके साथ, मैं एनक्रंच से ऑटोफिक्चर चेतावनी को पूरी तरह से हटाने के लिए तैयार हूं।

खैर, हमें अभी भी NUnit के साथ परेशानी है (हालांकि हम अपने रास्ते पर हैं), इसलिए यह संदेश NUnit परियोजनाओं के लिए प्रासंगिक प्रतीत होता है। शायद, यह केवल xUnit के लिए अक्षम करने के लिए समझ में आता है, जब तक कि हम NUnit के लिए पूर्ण समर्थन (या कम से कम उस समर्थन को सक्षम करने का एक तरीका) पेश नहीं करते।

मेरे पास अभी भी एक बात है जो मेरे लिए अस्पष्ट है। इसका क्या अर्थ है कि आप समर्थन नहीं करते जैसे AutoFixture और NUnit? हां, हर बार परीक्षण के नाम अलग-अलग होते हैं, लेकिन क्या इससे कोई फर्क पड़ता है कि आप सभी परीक्षणों को फिर से चलाते हैं (यदि इंजन मोड ऐसा सेट किया गया है)? या इसका मतलब यह है कि आप उनके लिए "केवल प्रभावित" इंजन का अधिक समर्थन नहीं करते हैं? मेरा विचार यह था कि No support कहने के बजाय, कुछ विशेष परिदृश्यों को सीमित करना बेहतर है, जिनका हम समर्थन नहीं करते हैं, जबकि बाकी को ठीक होना चाहिए।

'प्रभावित परीक्षण स्वचालित रूप से चलाएं, अन्य मैन्युअल रूप से'

मैं अपने 3.10.0.20 इंस्टालेशन पर यह सेटिंग नहीं ढूंढ पाया। क्या आपका मतलब Only consider tests 'Out of date' if they are 'Impacted' सेटिंग है जिसे true सेट किया जाना चाहिए? क्षमा करें अगर मुझे वह कहीं याद आया - मैं इस उत्पाद के लिए थोड़ा नया हूँ ..

दस्तावेज़ीकरण अद्यतन

शायद इस पृष्ठ से xUnit और AutoFixture के साथ _remove_ मामले को नहीं निकालना समझ में आता है, लेकिन इसके बजाय इसका सही तरीके से उपयोग करने का वर्णन करें ( DisableDiscoveryEnumeration विशेषता का उपयोग करें)। इसके अलावा यह XUnit के लिए "NUnit टेस्ट केस के साथ असंगत नाम" नमूना वर्णन करने के लिए शांत और उपयोग करने के लिए पूछना होगा DisableDiscoveryEnumeration के साथ एक साथ विशेषता MemberDataAttribute ।

मेरे पास अभी भी एक बात है जो मेरे लिए अस्पष्ट है। इसका क्या अर्थ है कि आप समर्थन नहीं करते जैसे AutoFixture और NUnit? हां, हर बार परीक्षण के नाम अलग-अलग होते हैं, लेकिन क्या इससे कोई फर्क पड़ता है कि आप सभी परीक्षणों को फिर से चलाते हैं (यदि इंजन मोड ऐसा सेट किया गया है)? या इसका मतलब यह है कि आप उनके लिए "केवल प्रभावित" इंजन का अधिक समर्थन नहीं करते हैं? मेरा विचार यह था कि नो सपोर्ट कहने के बजाय, कुछ विशेष परिदृश्यों को सीमित करना बेहतर है, जिनका हम समर्थन नहीं करते हैं, जबकि बाकी को ठीक होना चाहिए।

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

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

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

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

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

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

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

मैं इस सेटिंग को अपने 3.10.0.20 इंस्टॉलेशन पर नहीं ढूंढ पा रहा था। क्या आपका मतलब केवल 'आउट ऑफ डेट' परीक्षणों पर विचार करना है यदि वे 'प्रभावित' सेटिंग हैं जिन्हें सत्य पर सेट किया जाना चाहिए? क्षमा करें अगर मुझे वह कहीं याद आया - मैं इस उत्पाद के लिए थोड़ा नया हूँ ..

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

@remcomulder वाह! इतनी विस्तृत व्याख्या के लिए धन्यवाद! अब मैं देखता हूं कि वास्तव में यह कहना आसान है कि AutoFixture और NUnit वर्तमान में समर्थित नहीं है क्योंकि हुड के तहत कुछ बड़ी समस्याएं हैं

मैं अब भी मानता हूं कि इन मुद्दों को हल करने का सबसे अच्छा तरीका अस्थिर मापदंडों की लगातार सीडिंग करना है।

दरअसल, इस पीआर में हमारा आइडिया कुछ अलग है। हम परीक्षण के नाम को बदलना चाहते हैं ताकि यह स्थिर रहे। उदाहरण के लिए, इस तरह दिया गया परीक्षण:

    [Test, StableNameAutoData]
    public void Sample(int a, Data d1, DataWithToString d2, ISomeData d3)
    {
        Assert.IsTrue(true);
    }

परीक्षण का नाम होगा:

NUnit3RunnerTest709.TestNameTester.Sample(auto<System.Int32>,auto<NUnit3RunnerTest709.Data>,auto<NUnit3RunnerTest709.DataWithToString>,auto<Castle.Proxies.ISomeDataProxy>)

प्रत्येक खोज/निष्पादन के दौरान नाम हमेशा समान रहेगा, जबकि वास्तविक तर्क मान हर बार भिन्न होंगे।

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

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

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

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

दुर्भाग्य से एनयूनीट के बारे में मेरा ज्ञान गहरे से बहुत दूर है :( एनक्रंच मूल रूप से केवल एनयूनीट नाम को वापस लेता है, और पहचानकर्ता उत्पन्न करने के लिए इसका उपयोग करता है। इसलिए सिद्धांत रूप में, जब तक आपका समाधान परीक्षण के भौतिक नाम को बदलता/स्थिर करता है NUnit API द्वारा लौटाया गया, तो हमें यहाँ ठीक होना चाहिए
कम से कम एनक्रंच के लिए।

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

@remcomulder बस आपको अपडेट करने के लिए, ताकि हम अंत में इस मुद्दे को बंद कर सकें।

जैसा कि ऊपर चर्चा की गई है, xUnit ढांचे को मूल रूप से समर्थित किया जा रहा है। हालांकि, NUnit के लिए समस्या स्पष्ट नहीं थी क्योंकि यह अस्थिर नामों वाले परीक्षणों का समर्थन नहीं करता है।

हमने हाल ही में एक पीआर का विलय किया है और ऑटोफिक्चर का एक नया संस्करण ( v3.51.0 ) जारी किया है जो NUnit के लिए स्थिर नामों के लिए समर्थन जोड़ता है। अभी के लिए, उपयोगकर्ता की ओर से मैन्युअल क्रियाओं की आवश्यकता है ( यहां देखें), हालांकि v4 में मैं इसे आउट-ऑफ-द-बॉक्स बनाने जा रहा हूं।

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

@zvirja इस पर मुझे लूप करने के लिए धन्यवाद। मैंने इस कार्य का त्वरित परीक्षण किया है, और यह मुझे ठोस लग रहा है। परीक्षण नामों से यादृच्छिक तत्वों को हटाकर, धावक लगातार सत्रों में परीक्षणों की पहचान कर सकता है और सब ठीक लगता है :)

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

मैं ध्यान देता हूं कि डिफ़ॉल्ट रूप से, AutoFixture VolatileNameTestMethodBuilder का उपयोग करेगा। मैं स्वीकार करता हूं कि यह पिछड़ी संगतता के कारण है और मैं मानता हूं कि यह समझदार है। लेकिन क्या होगा अगर हम एक पर्यावरण चर का उपयोग करके इस डिफ़ॉल्ट को ओवरराइड करने की अनुमति दें? यदि हम AutoFixture को VolatileNameTestMethodBuilder का उपयोग करने के लिए बाध्य करने के लिए एक पर्यावरण चर (जैसे, 'AutoFixture.FixedTestNames'=='1') निर्दिष्ट कर सकते हैं, तो उपयोगकर्ता के लिए कुछ भी करने की आवश्यकता के बिना, एक धावक के लिए बिल्डर को पहले से निर्दिष्ट करना संभव होगा। यह उन लोगों के लिए भी एक बोनस होगा जो कई धावकों का उपयोग करते हैं, क्योंकि वे प्रत्येक धावक के लिए अलग-अलग बिल्डरों का उपयोग कर सकते हैं (बिना किसी प्रयास के) और दोनों दुनिया के सर्वश्रेष्ठ प्राप्त कर सकते हैं।

तुम क्या सोचते हो?

मैंने इस कार्य का त्वरित परीक्षण किया है, और यह मुझे ठोस लग रहा है।

वह तो कमाल है! इसका मतलब है कि हम इस मुद्दे को बंद कर सकते हैं क्योंकि अब सब कुछ ठीक चल रहा है। परीक्षण और यहां आपकी भागीदारी के लिए धन्यवाद

तुम क्या सोचते हो?

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

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

मुझे लगता है कि मैं एक बेहतर और सरल समाधान के साथ समाप्त हुआ - हम FixedNameTestMethodBuilder को v4 (हमारी अगली प्रमुख रिलीज़) में एक डिफ़ॉल्ट रणनीति बना देंगे जो आगामी महीने या दो में जारी की जाएगी।

यह मेरे लिए बहुत अच्छा काम करेगा :) मैं खुश हूँ! आपके सभी प्रयास के लिए धन्यवाद।

बढ़िया आपके उत्तरों और सहयोग के लिए फिर से धन्यवाद

मैं इसे बंद कर रहा हूं क्योंकि दोनों पक्षों से अधिक किसी कार्रवाई की आवश्यकता नहीं है।

@remcomulder @zvirja बस यह कहना चाहता था कि यह चर्चा (जिसने मुझे इसी तरह के मुद्दे को समझने में मदद की), और आपने यहां जो समर्पण दिखाया है, वह कमाल के अलावा और कुछ नहीं है! आपके महान उत्पादों के लिए आप दोनों को धन्यवाद।