Nunit: उदाहरण-प्रति-परीक्षण-मामला सुविधा

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

मेरा विचार यह है कि हम किसी भी समय, यदि कभी भी, किसी भी समय डिफ़ॉल्ट नहीं बदल सकते हैं। परिवर्तनशील स्थिति होने से वर्तमान में बग की गारंटी नहीं है। यह केवल एक बग है यदि आप वास्तव में इसे बदलते हैं और हम नहीं जानते कि जब तक हम कोड विश्लेषण नहीं करते - जो कि नहीं करते हैं!

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

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

मैं @CharliePoole के साथ हूं, डिफ़ॉल्ट को वैसे ही रहना है और इसे हटाया नहीं जा सकता है अन्यथा यह उन लोगों को तोड़ सकता है जो उस व्यवहार को चाहते हैं।

हो सकता है कि सभी थ्रेड के लिए साझा किए गए उदाहरण के बजाय प्रति थ्रेड इंस्टेंस ट्रिगर करने के लिए एक स्थिरता स्तर विशेषता हो।

@BlythMeister चिंता मत करो! हम ऐसे किसी भी बदलाव पर विचार नहीं कर रहे हैं जिससे मौजूदा कोड टूटना शुरू हो जाए।

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

हाँ, मैं थ्रेड शब्द का उपयोग समानांतर निष्पादन के लिए कर रहा हूँ .... जो तथ्यात्मक रूप से गलत है।
मैं क्षमाप्रार्थी हूं।

XP के संदर्भ में (और मुझे आशा है कि हर कोई जानता है कि यह हमेशा मेरा दृष्टिकोण है) हमारे पास तीन कहानियां हैं, जो एक दूसरे पर आधारित हैं ...

1. उपयोगकर्ता असेंबली में सभी फिक्स्चर के लिए विश्व स्तर पर इंस्टेंस-प्रति-टेस्ट-केस व्यवहार निर्दिष्ट कर सकता है।

2. उपयोगकर्ता एक फिक्स्चर पर उदाहरण-प्रति-परीक्षण-मामला व्यवहार निर्दिष्ट कर सकता है।

3. उपयोगकर्ता फिक्स्चर के लिए उदाहरण-प्रति-परीक्षण-मामला व्यवहार निर्दिष्ट कर सकते हैं जिसमें परीक्षण होते हैं जो समानांतर में चल सकते हैं।

मैं देखना चाहता हूं (1) इस मुद्दे में पूरी तरह कार्यान्वित। मुझे लगता है कि हमें बस (2) हमारे सिर से बाहर रखना चाहिए - या कम से कम उस हिस्से से जो कोड लिखता है - फिलहाल। मुझे लगता है कि (3) एक संभावना है, लेकिन कुछ नुकसान हैं जिनका हम पहले ही अन्य मुद्दों में सामना कर चुके हैं। (एक फिक्स्चर यह नहीं जानता कि क्या उसके पास समानांतर में परीक्षण मामले चलेंगे!) आइए उस JustInTime के बारे में बात करते हैं, जो (1) और (2) के बाद पूर्ण और विलय हो जाएगा। एफडब्ल्यूआईडब्ल्यू, मुझे लगता है कि हम कई कदम आगे सोचने की कोशिश करके गांठों में बंधे होने की प्रवृत्ति रखते हैं। मैंने (2) और (3) का उल्लेख किया है ताकि हम उन्हें किसी भी तरह से ब्लॉक न करें, जिससे बचना काफी आसान लगता है।

मुझे लगता है कि हम सभी तब सहमत हैं। हालांकि इससे पहले मेरी कुछ NUnit प्राथमिकताएं हैं, इसलिए मैं इसे दूसरों पर टिप्पणी करने और संभवतः लेने के लिए छोड़ दूंगा।

कमांड-लाइन सेटिंग के बजाय एक विशेषता के साथ ऐसा करने की सुंदरता यह है कि यह किसी भी धावक के लिए काम करेगा।

मैं @CharliePoole से सहमत हूं कि यह एक विशेषता होनी चाहिए। टेस्ट को प्रति परीक्षण या उदाहरण प्रति स्थिरता को ध्यान में रखते हुए डिजाइन करने की आवश्यकता होगी, इसलिए उन्हें हमेशा उसी तरह चलाना चाहिए। मैं भी केवल विकल्प 1 करना पसंद करता हूं। मुझे लगता है कि यदि आप परीक्षण की उस शैली को चाहते हैं, तो आपको इसे अपने संपूर्ण परीक्षण सूट के लिए ऑप्ट-इन करना चाहिए। आपको निचले स्तरों पर ऑप्ट-इन करने की अनुमति देना जटिलता का परिचय देता है जो मुझे नहीं लगता कि एक अच्छा आरओआई है।

बस उत्सुक हैं कि क्या इस सुविधा को लागू करने की कोई आसन्न योजना है?

@rprouse इसे अभी भी डिज़ाइन की आवश्यकता के रूप में चिह्नित किया गया है, लेकिन ऐसा लगता है कि चर्चा में पहले से ही सब कुछ शामिल है।

@CharliePoole ने सहमति व्यक्त की कि यह डिजाइन से आगे बढ़ सकता है। @pfluegs हमने इसे डिजाइन करने के अलावा इस पर काम करना शुरू नहीं किया है, इसलिए अभी तक कोई योजना नहीं है।

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

मुझे इस मुद्दे से बुरी तरह काटा गया है - फिक्स के लिए +1।

यदि हम कभी और विकल्प चाहते हैं, तो क्या हम चाहेंगे:

```सी#
[असेंबली: फिक्सचर क्रिएशन (फिक्चर क्रिएशनऑप्शन। परटेस्टकेस)]

And:
```diff
namespace NUnit.Framework
{
+   public enum FixtureCreationOptions
+   {
+       Singleton, // = default
+       PerTestCase
+   }
}

कम से कम एक नए ढांचे के संदर्भ में, इस पर मेरी अपनी सोच थोड़ी बदल गई है।

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

@CharliePoole [TestFixture(FixtureOptions.PerTestCase)] एक अच्छा सिंटैक्स की तरह लगता है, लेकिन मैं दृढ़ता से एक असेंबली-स्तरीय विशेषता भी चाहता हूं ताकि मैं प्रत्येक परीक्षण प्रोजेक्ट के साथ ऑप्ट इन कर सकूं। हम असेंबली-स्तरीय विशेषता को कैसा दिखाना चाहेंगे?

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

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

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

@ nunit/ढांचा-टीम आप क्या सोचते हैं? सुविधा के प्रारंभिक परिचय के लिए:

• असेंबली-स्तरीय सेटिंग के लिए हां/नहीं?
• स्थिरता-स्तर सेटिंग के लिए हाँ/नहीं?
• विधि-स्तर सेटिंग के लिए हाँ/नहीं?
• टेस्ट-केस-लेवल सेटिंग के लिए हां/नहीं?

विशेषताहीन स्थिरता वर्गों के बारे में अच्छी बात।

मैं कहूँगा हाँ, हाँ, नहीं, नहीं

मैं चार्ली से सहमत हूं - इस स्पष्टीकरण के साथ कि 'स्थिरता-स्तर' का अर्थ 'वर्ग-स्तर' है। (उदाहरण के लिए एक परीक्षण केस स्रोत विधि के विपरीत। )

यह सहायता करता है! तो [TestFixture(FixtureCreationOptions.PerTestCase)] साथ समस्या यह है कि एक ही कक्षा में एकाधिक TestFixture विशेषताओं की अनुमति है और फिर वे एक-दूसरे का खंडन कर सकते हैं। असेंबली और कक्षाओं पर लागू होने वाली नई नामित विशेषता के लिए बेहतर और सरल हो सकता है?

```सी#
[असेंबली: ShareFixtureInstances(false)]

[शेयरफिक्चर इंस्टेंस (झूठा)]
सार्वजनिक वर्ग कुछ स्थिरता
{
//...
}

Framework API:

```diff
namespace NUnit.Framework
{
+   [AttributeUsage(AttributeTargets.Assembly | AttributeTargets.Class)]
+   public sealed class ShareFixtureInstancesAttribute : PropertyAttribute
+   {
+       public bool ShareFixtureInstances { get; }

+       public ShareFixtureInstancesAttribute(bool shareFixtureInstances);
+   }
}

बढ़िया है। इसका विरासत व्यवहार क्या है - यदि मेरे पास बेस क्लास पर अपने स्वयं के परीक्षणों के साथ विशेषता है, और फिर उस वर्ग से भी प्राप्त होता है? मैं

संभवतः, चूंकि यह एक 'वर्ग' विशेषता है - यह वास्तविक वर्ग पर होना चाहिए, प्रश्न में परीक्षण चलाए जा रहे हैं?

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

कैसे InstancePerTest की तर्ज पर कुछ के बारे में...लेकिन बेहतर नाम...

विधानसभा और कक्षा स्तर के बारे में सहमत लेकिन गहरा नहीं। मैं @ChrisMaddock के सुझाव ClassInstancePerTest(bool) की तर्ज पर भी कुछ पसंद करता हूं। मैं यह भी मानता हूं कि कक्षा स्तर पर विशेषता असेंबली स्तर को ओवरराइड कर देगी और मुझे उम्मीद है कि यह विरासत में होगी। मुझे लगता है कि विरासत महत्वपूर्ण है क्योंकि आप आम तौर पर समानता के साथ संयुक्त वर्ग के सदस्यों के आधार पर प्रति परीक्षण एक उदाहरण चाहते हैं। इसलिए आप चाहते हैं कि स्वचालित रूप से व्युत्पन्न कक्षाओं पर लागू हो।

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

यह जानने के बाद। मैं, @ jnm2 की तरह, मैन्युअल रूप से परीक्षणों को हूं । लेकिन जब परीक्षण जैसे फाइलें बनाना और हटाना, केस रनर वास्तव में बोझिल हो जाते हैं: उन्हें आईडीस्पोजेबल होना चाहिए; अब आपके लिए कोई जादुई [TearDown] नहीं है। :( मचान त्रुटियों से परीक्षण त्रुटियों को बताने का कोई सुसंगत तरीका नहीं है। यह वास्तव में दर्दनाक उपयोग का मामला है।

अगर मैं डिजाइन पर रोक लगा सकता हूं, तो मैं

नाम PerTestInstance , InstancePerTest या कुछ है कि लगता है के लिए समान बहुत से बेहतर ShareFixtureInstances । मैं विशेषता के नाम पर Class शब्द को हल्के ढंग से नापसंद करता हूं, क्योंकि जब मैं एफ # कोड का परीक्षण कर रहा हूं, तो मुझे नहीं लगता कि टाइप इंस्टेंस क्लास हैं । लेकिन निश्चित बात मैं उसके साथ रह सकता हूँ! :)

ओह बॉय, इस फीचर के लिए और इंतजार नहीं कर सकता!

@ kkm000 मैं "वर्ग" के उपयोग के बारे में सहमत हूं। NUnit ने आमतौर पर ऐसे नामों का उपयोग किया है जो कार्यान्वयन से अलग हैं। फिर भी, लोग धारणाएँ बनाते हैं, लेकिन ऐसी चीज़ों से बचने में लगातार बने रहना बेहतर है।

मैं किस बारे में बात कर रहा हूं उसके उदाहरण: टेस्ट, टेस्टफिक्चर, सेटअपफिक्चर, वर्कर (थ्रेड नहीं), आदि। प्रिंसिपल में, एक वर्ग __ एक एकल परीक्षण का प्रतिनिधित्व कर सकता है, न कि एक स्थिरता ... मैं यह नहीं कह रहा हूं कि हम ऐसा करते हैं या यहां तक ​​​​कि चाहिए, लेकिन __हम कर सकते हैं__।

@kkm000

टिप्पणी के लिए धन्यवाद! आप बिल्कुल नहीं घुस रहे हैं। जहां संभव हो वहां भाषा-अज्ञेयवादी होने का हमारा एक डिज़ाइन लक्ष्य है।
सी # पर ध्यान देने के अलावा, class शब्द के बारे में एक और बात: क्या होगा यदि एक दिन हम ऐसे फिक्स्चर का समर्थन करते हैं जो कक्षाएं नहीं हैं?

[InstancePerTestCase] इस मुद्दे को दरकिनार कर देगा, लेकिन यह सहज स्पष्टता खो सकता है।

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

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

```सी#
सार्वजनिक स्थैतिक वर्ग SomeTestSuite // कोई स्थिरता नहीं: कोई सेटअप / टियरडाउन तर्क नहीं और कोई परीक्षण स्थिति नहीं
{
[टेस्ट] // सिंगल टेस्ट, पैरामीटराइज्ड सूट नहीं;
// स्थिरता को इस पैरामीटर के निहित के बजाय एक पैरामीटर के माध्यम से इंजेक्ट किया जाता है
सार्वजनिक स्थैतिक शून्य कुछ परीक्षण (कुछ स्थिरता स्थिरता)
{
स्थिरता। कुछ सेवा। कुछ संपत्ति = सच;
स्थिरता। कुछ एक्शन ();
स्थिरता। जोर कुछ ();
}
}

[टेस्टफिक्चर]
सार्वजनिक संरचना SomeFixture : IDISposable
{
सार्वजनिक कुछ सेवा कुछ सेवा {प्राप्त करें; } // राज्य

public SomeFixture() // This was almost legal syntax in C# 6, but I'm making a point 😁
{
    // Setup
}

public void Dispose()
{
    // Teardown
}

public void SomeAction()
{
    // Helper method
}

public void AssertSomething()
{
    // Helper method
}

}
```

उपरोक्त उदाहरण में, [FixtureInstancePerTestCase] या [SharedFixtureInstances(false)] कक्षाओं पर केंद्रित नहीं है और पदानुक्रम (सूट) पर केंद्रित नहीं है: यह फिक्स्चर पर केंद्रित है, और फिक्स्चर पुन: प्रयोज्य सेटअप/टियरडाउन तर्क और स्थिति हैं। विशेष रूप से, यह इस बात पर केंद्रित है कि क्या प्रत्येक परीक्षण मामले के लिए एक नया SomeFixture बनाया गया है या क्या प्रत्येक परीक्षण के लिए वही पास किया गया है।

चूंकि यह विशेषता नियंत्रित करेगी कि क्या विभिन्न ITests ITest.Fixture उदाहरणों को साझा करेंगे, और नियंत्रित की जाने वाली चीज़ वह है जिसे हम [TestFixture] (नाम में Fixture साथ एक और विशेषता) से सजाते हैं, ऐसा लगता है स्थिरता शब्द का उपयोग करने के लिए _consistent_ विकल्प।

(मैं ऐसे बिंदु ला रहा हूं जिन पर चर्चा करना महत्वपूर्ण लगता है, लेकिन नाम के अंत में मैं सुपर निवेशित नहीं हूं।)

@ जेएनएम 2 आप बिल्कुल सही हैं कि एक सूट और एक स्थिरता की अवधारणा अलग-अलग हैं। हालाँकि, NUnit ने उन सभी xunit परीक्षण ढाँचों के उदाहरण का अनुसरण किया, जो उस समय मौजूद थे जब इसे दोनों के संयोजन में बनाया गया था। यह स्थिरता साझा करने में अन्य ढांचे से विचलित हो गया।

मेरे ज्ञान के लिए, xunit.net परीक्षण विरासत पदानुक्रम से स्थिरता को एक अलग इकाई बनाने के लिए पहला (केवल?) ढांचा था।

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

मुझे लगता है कि लोग कभी-कभी (समानता से पहले) उदाहरण-प्रति-मामले व्यवहार के बारे में पूछते हैं कि यह अन्य ढांचे क्या करते हैं। इसी कारण से उन्होंने अलग-अलग फिक्स्चर के लिए __did__ नहीं पूछा।

तो, संक्षेप में, यहाँ मैं क्या सोचता हूँ ...

1. हमें प्रति टेस्ट केस व्यवहार के उदाहरण की आवश्यकता है।

2. पश्चगामी संगतता के कारण यह डिफ़ॉल्ट नहीं हो सकता।

3. एक अलग करने योग्य स्थिरता एक अच्छा विचार है, लेकिन यह भी एक अलग मुद्दा है।

4. वियोज्य फिक्स्चर इंस्टेंस फिक्स्चर के अनुसार लागू करने के लिए कम से कम जटिल दिखते हैं। बेशक आपको इस मामले में पिछड़ी संगतता से निपटना नहीं पड़ेगा, जिससे यह आसान हो जाता है।

केवल अंक ३ और ४ के बारे में पुष्टि करने के लिए, मैंने अपने कोड नमूने को नई सुविधाओं के लिए सुझाव के रूप में नहीं, बल्कि इस विशेषता के लिए सही नाम पर पहुंचने में हमारी मदद करने के लिए एक विचार प्रयोग के रूप में बनाया है। सोचा प्रयोग मुझे बताता है कि हम वास्तव में एक स्थिरता के विचार पर ध्यान केंद्रित कर रहे हैं, न कि एक वर्ग या एक सूट, भले ही वे अभी मेल खाते हों।

वे जो भी रूप लेते हैं, फिक्स्चर सेटअप/टियरडाउन/राज्य की पुन: प्रयोज्य परिभाषाएं हैं। मेरा मानना ​​है कि इस शब्द का अर्थ है। फिक्स्चर इंस्टेंस (सेटअप/टियरडाउन/स्टेट की घटनाएं) वही हैं जो हमारी नई विशेषता परीक्षण मामलों के बीच साझा करने या साझा करने का निर्णय लेती है। मुझे लगता है कि नाम में कहीं न कहीं FixtureInstances अधिकतम स्पष्टता लाएगा।

क्या यह सबको सही लगता है? यदि नहीं, तो हम और किन बिंदुओं पर विचार कर सकते हैं?

आह! क्षमा करें, मुझे लगा कि आपने बहुत अच्छे बिंदु पर प्रहार किया है, जिसे आमतौर पर अनदेखा कर दिया जाता है, लेकिन मुझे यह भी डर था कि हम पीछे हट रहे हैं। : थोड़ा_भ्रम_चेहरा:

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

हाँ, अच्छा बिंदु।

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

आइए कुछ विकल्प प्राप्त करें और हम वहां से ट्वीक कर सकते हैं।
हम कुछ ऐसा ढूंढ रहे हैं जो सहज ज्ञान युक्त, NUnit की शैली के साथ एकरूपता, और लचीलेपन की सही मात्रा को संतुलित करे। (अधिकांश भाग के लिए, ये चीजें पहले से ही ओवरलैप होनी चाहिए। )

प्रस्ताव ए

```सी#
[विधानसभा: स्थिरता विकल्प (InstancePerTestCase = true)]

[FixtureOptions(InstancePerTestCase = false)]
कक्षा कुछ स्थिरता
{
}

Pro: extending later if there's ever more options for fixture handling (doubtful?)
Pro: two names so there's less stuffed into a single name
Con: `[FixtureOptions]` would be legal but highly misunderstandable syntax. (Does it reset the assembly-wide setting to the default, `false`, or does it have no effect, e.g. `null`?)


### Proposal B

```c#
[assembly: FixtureOptions(FixtureCreationOptions.PerTestCase)]

[FixtureOptions(FixtureCreationOptions.Singleton)]
class SomeFixture
{
}

public enum FixtureCreationOptions
{
    Singleton, // = default
    PerTestCase,
    // Doubtful there will be other options?
    // Maybe Pool, where we reset and reuse between nonconcurrent tests?    
}

प्रो: अमान्य राज्य अप्रतिष्ठित हैं
प्रो: बाद में विस्तार करना यदि स्थिरता से निपटने के लिए और अधिक विकल्प हैं (संदिग्ध?)
कॉन: विशेषता नाम और एनम नाम दोनों टाइप करने में अतिरेक

प्रस्ताव सी

```सी#
[असेंबली: फिक्सचर इंस्टेंसपेरटेस्टकेस]

[FixtureInstancePerTestCase(false)]
कक्षा कुछ स्थिरता
{
}
```

प्रो: अमान्य राज्य अप्रतिष्ठित हैं
प्रो: गलत समझना मुश्किल है (लेकिन मेरे पास यहां एक अंधा स्थान है क्योंकि मैं एक नया उपयोगकर्ता नहीं हूं)
साथ: लंबा नाम
शायद कॉन: बहुत विशिष्ट नाम जो विकल्प और मूल्य दोनों को निर्दिष्ट कर सकता है। (लेकिन हमारे पास [NonParallelizable] जो मुझे पसंद है।)

(वैकल्पिक प्रस्तावों का स्वागत है!)

दो विशेषताएँ होने के लिए कुछ कहा जाना चाहिए: एक असेंबली के लिए और एक क्लास के लिए।

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

अपने प्रत्येक विकल्प का उपयोग करके दृष्टिकोण:

```सी#
[असेंबली: DefaultFixtureOptions (InstancePerTestCase = true)]

[FixtureOptions(InstancePerTestCase = false)]
कक्षा कुछ स्थिरता
{
}

[विधानसभा: DefaultFixtureOptions(FixtureCreationOptions.PerTestCase)]

[FixtureOptions(FixtureCreationOptions.Singleton)]
कक्षा कुछ स्थिरता
{
}

[विधानसभा: DefaultFixtureInstancePerTestCase]

[FixtureInstancePerTestCase(false)]
कक्षा कुछ स्थिरता
{
}
```

अन्य टिप्पणियां:

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

बीटीडब्लू, मैंने अक्सर कामना की है कि हम असेंबली और स्थिरता स्तरों के लिए DefaultTestCaseTimeOut के साथ गए थे और टाइमआउट को केवल विधियों के लिए रखा था।

अच्छा, इस संभावना को सामने लाने के लिए धन्यवाद।

अभी मुझे कुछ परेशान कर रहा है कि यह सैद्धांतिक रूप से समझ में आता है, भले ही हम इस दिशा में नहीं जा रहे हैं:

c# [DefaultFixtureOptions(InstancePerTestCase = true)] class SomeFixture { [FixtureOptions(InstancePerTestCase = false)] public void SomeTest() { } }

क्योंकि जिस स्तर पर यह वास्तव में खेलता है वह स्थिरता स्तर नहीं बल्कि टेस्ट केस स्तर है।
उदाहरण के तौर पर: एक व्युत्पन्न स्थिरता आधार स्थिरता की सेटिंग को ओवरराइड कर सकती है, लेकिन यह वास्तव में व्युत्पन्न वर्ग द्वारा उत्पादित प्रत्येक टेस्ट केस की सेटिंग को प्रभावित कर रही है।

या:

```सी#
[असेंबली: DefaultFixtureOptions (InstancePerTestCase = true)]

// इसे डिफ़ॉल्ट क्यों नहीं माना जाना चाहिए?
[DefaultFixtureOptions(InstancePerTestCase = true)]
सार्वजनिक सार वर्ग बेसफिक्चर
{
}

सार्वजनिक मुहरबंद वर्ग कुछ स्थिरता: बेसफिक्चर
{
}
```

Default का उपयोग कब और कब नहीं करना है, इसके लिए हम तर्क के साथ कैसे आते हैं?

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

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

यदि किसी फिक्स्चर में दोनों प्रकार के परीक्षण हो सकते हैं, तो हमें इसे दो बार निष्पादित करना होगा, प्रत्येक मॉडल के लिए एक बार।

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

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

डब्लूआरटी सेटअप फिक्स्चर, बीटीडब्ल्यू, मुझे लगता है कि इसे तत्काल विकल्प निर्दिष्ट करने के लिए रनटाइम त्रुटि उत्पन्न करनी चाहिए। SetUpFixtures TestFixtures नहीं हैं।

अर्थात्, विशेषता A को आधार वर्ग पर और B को व्युत्पन्न वर्ग पर रखना A और B को सीधे आधार वर्ग पर रखने से अलग नहीं है। हमने इसे इस तरह से डिजाइन किया है क्योंकि उपयोगकर्ता के लिए कुछ और करना आश्चर्यजनक होगा।

ओह माय, मुझे बेस क्लास' या बेस मेथड की सेटिंग को बदलने के लिए [Apartment] या [Parallelizable] उम्मीद होगी!

यह सब मुझे समझ में आता है।

क्या हम FixtureCreationOptions जैसे एनम को चाहने से इंकार कर सकते हैं? PerTestCase , PerFixture , काल्पनिक ReusedPerTestCase ?

मैं की सादगी की ओर झुक रहा हूँ:

```सी#
[असेंबली: DefaultFixtureOptions (InstancePerTestCase = true)]

[FixtureOptions(InstancePerTestCase = false)]
कक्षा कुछ स्थिरता
{
}

Hypothetical other creation options would then be added this way:
```c#
[FixtureOptions(InstancePerTestCase = false, ReuseInstances = true)]

@ nunit/ढांचा-टीम आपकी प्राथमिकताएं क्या हैं?

के बारे में

[assembly: DefaultFixtureOptions(InstancePerTestCase = true)]

शायद सिर्फ मैं, लेकिन आम तौर पर मैं विशेषताओं को यह दर्शाता हूं कि चिह्नित वस्तु में एक निश्चित विशेषता है, अन्यथा मौजूद नहीं है; विशेषता के लिए तर्क, यदि कोई हो, उक्त विशेषता को परिष्कृत कर रहे हैं। उदाहरण के लिए, Serializable को लें - वस्तु क्रमबद्ध है, लेकिन यदि असंगठित है, तो यह नहीं है; InternalsVisibleTo-- कुछ विशिष्ट के लिए दृश्यमान आंतरिक, और तर्क इसे परिष्कृत करते हैं, अन्यथा आंतरिक किसी भी चीज़ के लिए दृश्यमान नहीं होते हैं, आदि। कुछ विशेषताएँ पैटर्न का पालन नहीं कर रही हैं, लेकिन ये आमतौर पर निम्न स्तर, e, g, CompilationRepresentation, MethodImpl हैं। ये आमतौर पर आवश्यक कंस्ट्रक्टर तर्कों के साथ आते हैं।

अब विचार करें
c# [assembly: DefaultFixtureOptions]
यह एक अच्छी तरह से गठित सी # है, क्योंकि InstancePerTestCase को असाइनमेंट वैकल्पिक है। यह शब्दार्थ रूप से क्या व्यक्त करता है?

मेरे लिए, [assembly: DefaultFixtureInstancePerTestCase] अधिक स्वाभाविक लगता है (इसके sesquipedalian नाम के अपवाद के साथ, लेकिन यह केवल एक राय है, सौंदर्य की दृष्टि से उचित नहीं है)। एक गुण, एक गुण। शायद इसे किसी पैरामीटर या वैकल्पिक रूप से व्यवस्थित गुणों की आवश्यकता नहीं है।

साथ ही, एक उपयोगकर्ता के रूप में, मुझे यह आश्चर्यजनक लगता है कि अलग-अलग नामों के साथ दो विशेषताएँ हैं, एक केवल असेंबली स्तर पर लागू होती है ( DefaultSomething ) और दूसरी केवल एक प्रकार के स्तर पर (सिर्फ Something ) . स्वाभाविक रूप से, मुझे समझ में नहीं आता कि "सीखा सबक" क्या था जिसका उल्लेख @CharliePoole ने समानांतर विशेषता के बारे में किया था , लेकिन द्वीप के इस तरफ से, यह जानने के लिए विशेषताओं की एक जोड़ी (इस उपयोगकर्ता की सतही सोच में) कहां करना होगा, यह हैरान करने वाला लगता है।

@ kkm000 मैं एक विशेषता के बारे में आपकी टिप्पणी से सहमत हूं जो एक विशेषता को व्यक्त करता है।

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

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

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

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

मान लें कि आपने अंतिम वाक्य में गलत बोला था - क्या _ "इस असेंबली में तत्काल टेस्ट फिक्स्चर प्रति ~ स्थिरता ~ टेस्ट केस में एक बार जब तक अन्यथा निर्दिष्ट न हो।" _ इरादा? या मैं गंभीरता से दायरे और मंशा को गलत समझ रहा हूँ?

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

दो अलग कार्यान्वयन

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

अंत में, मेरे लिए यह एक मामूली मुद्दा है, और मैं एक ही विशेषता के लिए दृढ़ता से महसूस नहीं करता और किसी भी तरह से व्यवस्थित विशेषताओं के साथ रह सकता हूं।

@ kkm000 हां, मेरा इरादा "प्रति परीक्षण मामले में एक बार" था।

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

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

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

इस मामले में, कम अस्पष्टता प्रतीत होती है, क्योंकि हम नाम में "प्रति परीक्षण मामले" का उपयोग कर रहे हैं ताकि मैं आसानी से किसी भी तरह से जा सकूं। मैं वैसे भी इस पर काम नहीं कर रहा हूं। :मुस्कुराओ:

इसके बारे में सोचने के लिए आओ, अगर टाइमआउट को टेस्टकेस टाइमआउट कहा जाता तो यह बेहतर होता!

मैं एकल [FixtureInstancePerTestCase] खुश हूं। उपयोगकर्ताओं पर कम से कम मानसिक बोझ लगता है।

@ nunit/framework-team क्या आप https://github.com/nunit/nunit/issues/2574#issuecomment -426347735 नीचे से एक दिशा तय करने में हमारी मदद कर सकते हैं?

[FixtureInstancePerTestCase] भी मेरा सबसे कम नापसंद विकल्प है। एक्स्टेंसिबिलिटी की कमी ही एकमात्र नकारात्मक पहलू है।

मुझे [FixtureOptions] समस्या पसंद नहीं है - मुझे लगता है कि यह बहुत भ्रमित करने वाला है। मैं व्यक्तिगत रूप से असेंबली और क्लास दोनों के लिए एक ही विशेषता पसंद करूंगा - मैं सराहना करता हूं कि इससे हमें टाइमआउट और पैरालेलिज़ेबल के लिए पहले समस्याएं हुईं - हालांकि जब इस नाम में "स्थिरता" है, तो यह मेरे लिए कम अस्पष्ट लगता है।

मैं व्यक्तिगत रूप से एनम विकल्प को पसंद करता हूं ... सिवाय इसके कि मैं यह नहीं सोच सकता कि इसे और अधिक संक्षिप्त बनाने के लिए इसे उचित रूप से कैसे नाम दिया जाए!

क्या इस पर कोई अपडेट है?

इस मुद्दे पर कोई भी अपडेट पोस्ट किया जाएगा।

कृपया कोई इस मुद्दे को हल कर सकता है ??
वर्तमान में हमें अपने सभी टेस्ट कोड को इस तरह लपेटना होगा:
csharp [Test] public void TestExample(){ using(var tc = new MyTestContext()){ //code goes here } }
इस सुविधा का उपयोग करके, हम परीक्षण संदर्भ को सेट अप पर आरंभीकृत कर सकते हैं और फाड़ने पर निपटाया जा सकता है और अभी भी थ्रेड सुरक्षित हो सकता है।

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

@एमसीचियाक
यदि यह समस्या जल्द ही ठीक नहीं की जाएगी, तो हम xUnit में माइग्रेशन पर विचार कर रहे हैं, क्योंकि xUnit में यह डिफ़ॉल्ट व्यवहार है: "xUnit.net प्रत्येक परीक्षण के लिए परीक्षण वर्ग का एक नया उदाहरण बनाता है" https://xunit .github.io/docs/shared-context

@LirazShay, @MChiciak मैं भी इस मुद्दे में भाग लेकिन @CharliePoole के अंकों के साथ सहमत हैं। इसलिए मैंने अपने परीक्षण-विशिष्ट फ़ील्ड बनाए हैं जो सेटअप [ThreadStatic] पर प्रारंभ किए गए हैं और यह ठीक काम करता है।

@dfal
अच्छे उपाय के लिए धन्यवाद!

मुझे यह अच्छा लगेगा। मेरे पास वर्तमान में नूनिट पर चल रहे हजारों परीक्षणों के साथ एक मौजूदा परीक्षण सूट है, जिसे साझा स्थिति के कारण आसानी से समानांतर नहीं किया जा सकता है। यदि यह विकल्प प्रदान किया जाता, तो हम अपने परीक्षण सूट को और अधिक आसानी से समानांतर करने में सक्षम होते।

एक विचार प्रयोग के रूप में, कल्पना कीजिए कि हमने टेस्टफिक्चर के काम करने के तरीके को बदल दिया है। यह क्या तोड़ देगा?

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

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

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

मैंने इस विचार-प्रयोग को यह सोचने में उपयोगी पाया कि फिक्स्चर के प्रति-टेस्ट-केस इंस्टेंटेशन को कैसे कार्यान्वित किया जाए। NUnit 3 में पेश किए जाने पर इसे स्पष्ट रूप से एक नई गैर-डिफ़ॉल्ट सुविधा होने की आवश्यकता है। NUnit 4 या किसी अन्य नए ढांचे (जैसे टेस्टसेंट्रिक) के लिए नया व्यवहार आसानी से डिफ़ॉल्ट हो सकता है।

एक नोट के रूप में, मैंने बहुत ही सरलता से कुछ MSTest के TestClass और TestMethod को क्रमशः TestFixture और Test , और पाया कि NUnit और MSTest के यहाँ अलग-अलग शब्दार्थ हैं। एमएसटीएस्ट प्रत्येक परीक्षण के लिए नए उदाहरण बनाता है, जहां मुझे यकीन है कि इसे पढ़ने वाला हर कोई जानता है, एनयूनीट टेस्टफिक्चर उदाहरणों का पुन: उपयोग करता है।

यह अच्छा होगा अगर मैं इस प्रवास को आसान बनाने के लिए TestFixture(lifeCycle = OneTestPerInstance)] या इसी तरह का लिख ​​सकूं।

_edit:_ वास्तव में, Setup विधि का उपयोग करने के लिए परीक्षणों को पोर्ट करने के बाद, यह वास्तव में मौजूदा कोड प्रारंभकर्ता/पहले/टियरडाउन कोड को एमएसटीएस्ट के तहत काफी यातना देता है, और अब सरल संपत्ति-प्रारंभकर्ता कन्स्ट्रक्टर है, जो बहुत अच्छा और अधिक पूर्ण है, इसलिए मुझे खुशी है कि मैंने अनुवाद किया। फिर भी, अनुकूलता की बात के रूप में, यह अच्छा होगा।

@ चार्लीपूल

कोई भी परीक्षण जो आदेश का उपयोग करता है और अन्य परीक्षणों को प्रभावित करने के लिए एक परीक्षण द्वारा किए गए राज्य परिवर्तनों पर निर्भर करता है।

आह, हाँ, तोड़ो, इन परीक्षणों को तोड़ो, सुंदर कृपया !!! मैं सोच सकता हूं कि यूनिट परीक्षण ढांचे का यह सबसे खराब दुरुपयोग है।

कोई भी स्थिरता-स्तर OneTimeSetUp

उह, मैंने हमेशा सोचा है कि यह प्रति प्रक्रिया एक बार चलाया जाता है ... मैंने हमेशा सोचा कि यह स्थिर क्यों नहीं है।

लेकिन हाँ, प्रदर्शन भी एक बहुत ही मान्य बिंदु है।

यह सुविधा अब 2 वर्षों से अधिक समय से चर्चा में है, मेरा मतलब आक्रामक नहीं है, लेकिन क्या वास्तव में निकट भविष्य में इसे लागू करने के लिए कोई ठोस और यथार्थवादी योजना है?

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

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

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

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

उदाहरण के लिए, जब मुझे पहली बार इस तथ्य का पता चला कि एक एनयूनीट टेस्टफिक्चर एक सिंगलटन है तो मैंने अपने 100+ टेस्ट फिक्स्चर को 500 से अधिक परीक्षणों के साथ थ्रेडसेफ में परिवर्तित कर दिया (और राइनोमॉक्स से मोक तक जाना पड़ा क्योंकि राइनोमॉक्स भी थ्रेडसेफ नहीं है) और यह लिया मुझे लगभग 4 सप्ताह (ईमानदार होने के लिए, राइनो -> Moq ने उस समय का अधिकांश समय लिया!)

आप सिद्धांत रूप में 100% सही हैं, लेकिन जब आपके पास ~ 7000+ यूनिट परीक्षणों का मौजूदा परीक्षण सूट है, तो उन्हें थ्रेड सुरक्षित होने के लिए फिर से लिखना एक बड़ा निवेश है।

सुनिश्चित नहीं है कि यह किसी अन्य ढांचे में जाने से अधिक निवेश है (इसे स्वचालित करने के लिए कुछ उपकरण हो सकते हैं) लेकिन मुझे नहीं लगता कि इस सुविधा अनुरोध को सिद्धांत पर छोड़ दिया जाना चाहिए, आईएमओ

मैं इस बात की वकालत नहीं कर रहा हूं कि इस सुविधा को नहीं देखा जाना चाहिए।

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

मैं सुझाव दे रहा हूं कि कोड को नूनिट का उपयोगकर्ता एक बहु थ्रेड वातावरण में चलाने के लिए थ्रेडसेफ लिखता है, यह कार्रवाई का एक आसान रूप है। आप संभवतः इसे स्क्रिप्ट भी कर सकते हैं।

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

यह पूरा मुद्दा विभिन्न तरीकों पर चर्चा कर रहा है कि एक वैकल्पिक स्विच लागू किया जा सकता है ... कई तरीके हैं

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

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

मैं अब पहले की तरह सक्रिय रूप से योगदान नहीं दे रहा हूं, इसलिए मेरी टिप्पणियों के रूप में मुझे लगता है कि इसे कैसे किया जाना चाहिए, इसे सलाह के रूप में दिया गया था जो इसे उठाता है।

मैं सहमत हूं कि यह कुछ समय के लिए रहा है और मुझे इसे स्वयं करते हुए देखना अच्छा लगेगा।

@BlythMeister मुझे लगता है कि एक स्विच इसे थोड़ा

ज़रूर, यह एक स्विच है, लेकिन यह सिर्फ एक लाइट बल्ब को चालू नहीं कर रहा है। यह आपके रेडियो को AM से FM पर स्विच करने जैसा है... पूरी तरह से नए सर्किट चलन में हैं।

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

क्षमा करें आपका अधिकार, मेरी व्याख्या अस्पष्ट थी कि "स्विच" सरल क्यों नहीं है!

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

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

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

@ चार्लीपूल

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

हम इंस्टेंस-प्रति-टेस्ट-केस सुविधा को लागू क्यों नहीं कर सकते हैं और अभी भी केवल एक बार वनटाइमसेटअप चला सकते हैं (मुख्य थ्रेड को इसे या कुछ कॉल करने के लिए याद रखें)?

क्योंकि यह किसी भी मौजूदा OneTimeSetUp को तोड़ देगा जिसने इंस्टेंस को प्रारंभ किया, जो कि बहुत आम है।

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

क्योंकि यह किसी भी मौजूदा OneTimeSetUp को तोड़ देगा जिसने इंस्टेंस को प्रारंभ किया, जो कि बहुत आम है।

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

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

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

मुझे लगता है कि मैं कम से कम आश्चर्य का प्रिंसिपल यहां अच्छा काम करता हूं। यदि कोई नया फिक्स्चर अलग तरीके से काम करता है तो यह आश्चर्यजनक नहीं है।

यदि, दूसरी ओर, हम एक ऐसा ध्वज बनाते हैं जो मौजूदा स्थिरता को नियंत्रित करता है, तो मैं वर्तमान कार्यान्वयन में पाँच या छह अलग-अलग स्थानों के बारे में सोच सकता हूँ जहाँ हमें उस ध्वज पर शाखा लगाने की आवश्यकता होगी।

यह कहना नहीं है कि दो स्थिरता प्रकार निश्चित कोड साझा नहीं कर सकते हैं। लेकिन यह यूजर्स की नजर से बाहर होगा।

@fschmied BTW, अगर हम एक नया ढांचा (या शायद NUnit 4) भी कर रहे थे, तो मैं अलग तरह से बहस करूंगा ... मुझे लगता है कि हमें NUnit 2 और 3 में एक दूसरे के साथ हस्तक्षेप करने के लिए परीक्षणों को बहुत कठिन बनाना चाहिए था। हालाँकि , जब तक हम NUnit 3 में परिवर्तन कर रहे हैं, मुझे लगता है कि संगतता नियम।

मैं टेस्टफिक्चर को पूरी तरह से नए प्रकार के फिक्स्चर के साथ बदलना पसंद करता हूं, जो अलग तरह से काम करता है।
[...]
मुझे लगता है कि मैं कम से कम आश्चर्य का प्रिंसिपल यहां अच्छा काम करता हूं। यदि कोई नया फिक्स्चर अलग तरीके से काम करता है तो यह आश्चर्यजनक नहीं है।

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

लेकिन निश्चित रूप से, यह पिछड़ी संगतता, कार्यान्वयन जटिलता और मूल पाप को ठीक करने की इच्छा के बीच एक व्यापार है [1]।

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

[१] जेम्स न्यूकिर्क ने यह लिखा है :

मुझे लगता है कि जब हमने NUnit V2.0 लिखा था, तो सबसे बड़ा पेंच-अप प्रत्येक निहित परीक्षण विधि के लिए परीक्षण स्थिरता वर्ग का एक नया उदाहरण नहीं बनाना था। मैं कहता हूं "हम" लेकिन मुझे लगता है कि यह मेरी गलती थी। मैं प्रत्येक परीक्षण विधि के लिए परीक्षण स्थिरता का एक नया उदाहरण बनाने के लिए जुनीट में तर्क को समझ नहीं पाया।

वह यह भी लिखता है, यद्यपि:

[...] जिस तरह से NUnit अब काम करता है उसे बदलना मुश्किल होगा, बहुत से लोग शिकायत करेंगे [...]

:)

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

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

तो .. क्या यह पकड़ने के लिए है? या अभी भी डिजाइन चरण में?

अभी .NET में बॉयलरप्लेट समानांतर परीक्षणों के साथ, टेस्टकॉन्टेक्स्ट या एनयूनीट के बिना या तो एक्सयूनीट भूमि है

सुविधा को स्वीकार किया जाता है और सामान्य प्राथमिकता दी जाती है। किसी को भी इसे सौंपा नहीं गया है और यह एक मील के पत्थर पर सूचीबद्ध नहीं है। इसका मतलब है कि किसी को यह तय करना होगा कि वे इस पर काम करना चाहते हैं। वह एक कमिटर या योगदानकर्ता हो सकता है।

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

तो, क्या आप इस पर काम करना चाहेंगे?

ज़रूर, मैंने अभी-अभी काम शुरू किया है
https://github.com/avilv/nunit/tree/instance-per-test

मैं इस कोडबेस के लिए नया हूं इसलिए मैं जितना हो सके मूल कोड शैली से चिपके रहने की कोशिश कर रहा हूं
अब तक मैंने एक InstancePerTestCase विशेषता पेश की है और इसे असेंबली और क्लास स्तर पर समर्थित करने की योजना है

मुझे बताएं कि क्या मैं यहां आधार से दूर हूं

मैंने आपकी अंतिम प्रतिबद्धता पर कुछ कार्यान्वयन विवरणों पर टिप्पणियां जोड़ीं।

जहां तक ​​​​डिजाइन की बात है, मुझे लगता है कि IApplyToContext से प्राप्त एक विशेषता समझ में आती है। मुझे लगता है कि मैं सिर्फ InstancePerTestCase की तुलना में कुछ अधिक सामान्य पसंद करूंगा, शायद

C# [FixtureLifeCycle(LifeCycle.InstancePerTestCase]

इससे आप इसे असेंबली स्तर पर सेट कर सकते हैं और इसे अलग-अलग फिक्स्चर पर रीसेट कर सकते हैं।

चार्लीपूल आप बहुत ज्यादा हैं, प्रतिक्रिया और मदद के लिए बहुत बहुत धन्यवाद

मुझे लगता है कि मैं समझ रहा हूं कि चीजें कैसे बनती हैं / क्या करता है आदि। धीरे-धीरे लेकिन निश्चित रूप से

लाइफसाइकल एनम के लिए मेरा प्रस्ताव यहां दिया गया है (ive ने आपके सुझाव के साथ मेरी शाखा को भी अपडेट किया है)

    /// <summary>
    /// Specifies the lifecycle for a fixture.
    /// </summary>
    public enum LifeCycle
    {
        /// <summary>
        /// A single instance is created and for all test cases.
        /// </summary>
        SingleInstance,

        /// <summary>
        /// A new instance is created for each test case for fixtures that are marked with <see cref="ParallelizableAttribute"/>.
        /// </summary>
        InstancePerTestCaseForParallelFixtures,

        /// <summary>
        /// A new instance is created for each test case.
        /// </summary>
        InstancePerTestCase
    }

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

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

मैं इस बात से भी सहमत हूं कि इसे किसी भी तरह से समानता के साथ नहीं जोड़ा जाना चाहिए। समांतरता इस सुविधा को जोड़ने का कारण था लेकिन एक बार जब हम सहमत हो जाते हैं कि यह सुविधा उपयोगी है, तो मेरी राय में, इसे कोड में प्रतिबिंबित नहीं किया जाना चाहिए

मैं सहमत हूं, मैं इसे केवल समानांतर परिदृश्यों में उपयोग करने के लिए उपयोग के मामले को समझता हूं, क्योंकि जहां से एनयूनीट का वर्तमान डिफ़ॉल्ट मॉडल आपको काटेगा, लेकिन उम्मीद है कि यह भविष्य में डिफ़ॉल्ट जीवन चक्र होगा (ननिट 4?) क्योंकि मुझे लगता है कि यह वास्तव में होना चाहिए शुरू से ऐसा रहा है

शायद हमें इसे SingleInsance/InstancePerTestCase पर छोड़ देना चाहिए

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

हम पहले से ही किसी भी परीक्षण स्थिरता का निपटान करते हैं जो IDisposable लागू करता है। आपको बस यह सुनिश्चित करने की ज़रूरत है कि यह काम करना जारी रखे।

बढ़िया, करेंगे।

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

DisposeFixtureCommand निपटान को कॉल करने का ख्याल रखता है।

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

@CharliePoole ऐसा लगता है कि आप सही हैं, मैंने परीक्षण विधि को वास्तव में निष्पादित करने पर थोड़ा सा रेखांकन किया है:

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

मैंने नवीनतम परिवर्तनों को अपडेट किया
https://github.com/avilv/nunit/tree/instance-per-test-2

हटा दिया गया इंस्टेंसपेरटेस्टकेसजब केस समानांतर हैं
CompositeWorkItem MakeOneTimeSetUpCommand में SimpleWorkItem में MakeTestCommand अंदर निर्माण / निपटान स्थिरता जोड़ने, और लंघन यह के माध्यम से कार्यान्वित किया FixtureLifeCycle

ऐसा लगता है कि यह अच्छी तरह से काम करता है, यह भी अधिक समझ में आता है कि ढांचा कैसे बनाया जाता है
अब मुझे यह सुनिश्चित करने के लिए यूनिट परीक्षणों का एक गुच्छा जोड़ने की जरूरत है कि यह सब ठीक से काम कर रहा है

किसी भी मौके पर अगले संस्करण से पहले इसकी समीक्षा की जाएगी? मैं अभी भी सुधार/पाठ्यक्रम में बदलाव के लिए तैयार हूं

यह दृष्टिकोण मेरे लिए अच्छा लगता है और अगर हम ऐसा कर सकते हैं तो मुझे अगली रिलीज में इसका इस्तेमाल करना अच्छा लगेगा!

किसी भी मौके पर हम इसकी समीक्षा कर सकते हैं? ऐसा लगता है कि वास्तव में करीब आ रहे थे

उत्सुक अगर इस सुविधा पर कोई हलचल हुई है? ऐसा लगता है कि @avilv ने इसे काफी करीब पा लिया है। लंबे समय से इस तरह की सुविधा की उम्मीद कर रहे हैं, और इसका उपयोग करने के लिए उत्साहित हैं!

सबको शुक्रीया!

क्या यह सुविधा अब काम कर रही है?

@CharliePoole आप समीक्षा @avilv नवीनतम संस्करण को खुश कर सकता है? ऐसा लगता है कि इसे पूरी तरह से लागू किया गया है। मुझे लगता है कि बहुत से लोग इस फीचर का इंतजार कर रहे हैं।

@janissimsons क्षमा करें, लेकिन मैं अब इस परियोजना पर नहीं हूं इसलिए मेरी समीक्षा इसे आगे नहीं

#3427 का विलय करने के लिए किए गए सभी कार्यों की सराहना करें। @rprouse क्या कोई विचार है जब हम एक रिलीज में इसकी उम्मीद कर सकते हैं?

हम नई सुविधा का उपयोग कैसे करते हैं? क्या कोई नई विशेषताओं के बारे में संक्षिप्त विवरण लिख सकता है और उनका सही तरीके से उपयोग कैसे कर सकता है?

मैं अगले कुछ हफ्तों में रिलीज करने की योजना बना रहा हूं। मैं तब तक इंतजार करना चाहता था। NET 5 अंतिम है और रिलीज से पहले इसके साथ कुछ अंतिम परीक्षण करें। मुझे संदेह है कि कोई समस्या होगी, लेकिन यह इतना करीब है कि मैंने सोचा कि इंतजार करना बेहतर होगा।

@rprouse कोई अनुमान है कि आप नया संस्करण कब जारी करने जा रहे हैं? मैं इस सुविधा का उपयोग शुरू करना चाहता हूं।

@janissimsons बहुत जल्द। हम अपने .NET 5.0 बिल्ड और कुछ अन्य मुद्दों के साथ कुछ मुद्दों पर काम कर रहे हैं, फिर मैं रिलीज करूंगा। आप इस परियोजना बोर्ड पर स्थिति को ट्रैक कर सकते हैं, https://github.com/nunit/nunit/projects/4

यह अद्भुत खबर है!

क्या मैं सही ढंग से समझता हूं कि इससे एनयूनीट में निम्नलिखित संभव हो जाएगा?

इन सभी को मिलाएं:

• टेस्ट पैरामीटरकृत हैं
• समानांतर में परीक्षण चलाएँ।
• समानांतर में एक ही परीक्षण के पैरामीटरयुक्त रूपांतरों को चलाने में सक्षम हो।
• टेस्ट डेटा संचालित हो सकते हैं

अतीत में यहां कुछ चीजों की कोशिश की https://github.com/jawn/dotnet-parallel-parameterized-tests

क्या नई रिलीज़ अभी भी .NET Full Framework 4.7.2 या कम से कम 4.8 के साथ संगत होगी?

सादर,
डॉ

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

@drauch हाँ, 3.13 रिलीज़ अभी भी .NET 3.5 पर वापस समर्थन करेगा।

@avilv बढ़िया काम !!
वैसे आपने किस उपकरण का उपयोग करके वह अच्छा प्रवाह आरेख बनाया है?
धन्यवाद

@rprouse क्या आप कृपया इस नई सुविधा का उपयोग करने के बारे में दस्तावेज़ीकरण भी अपडेट कर सकते हैं? धन्यवाद!

@janissimsons मैं रिलीज के लिए दस्तावेज़ों को अद्यतन करने की योजना बना रहा हूं। लघु संस्करण हालांकि आपकी परीक्षण कक्षा में [FixtureLifeCycle(LifeCycle.InstancePerTestCase)] जोड़ना है, शायद [Parallelizable(ParallelScope.All)] और कक्षा के भीतर चलने वाले प्रत्येक परीक्षण के लिए आपके परीक्षण वर्ग का एक उदाहरण तत्काल हो जाएगा। ऐसा करने से आप कक्षा में सदस्य चर का उपयोग समानांतर परीक्षण रन में कर सकते हैं, अन्य परीक्षणों के बारे में चिंता किए बिना चर बदलते हैं।

@LirazShay स्क्रीनशॉट में आरेख विजुअल स्टूडियो एंटरप्राइज में बनाया गया था। आप समाधान एक्सप्लोरर में चयन पर राइट-क्लिक कर सकते हैं और उदाहरण के लिए "कोड मैप पर दिखाएं" चुन सकते हैं। https://docs.microsoft.com/en-us/visualstudio/modeling/map-dependencies-across-your-solutions ReSharper में एक समान विशेषता है।

@jnm2 बहुत बहुत धन्यवाद !!!
मेरे पास वीएस एंटरप्राइज़ है और मुझे इस सुविधा के बारे में पता नहीं है जो बहुत उपयोगी हो सकता है
टिप के लिए बहुत बहुत धन्यवाद

क्या मैं सही हूं कि यह रिलीज हो चुकी है और 3.13 रिलीज का हिस्सा है?

क्या मैं सही हूं कि यह रिलीज हो चुकी है और 3.13 रिलीज का हिस्सा है?

मेरा मानना ​​​​है कि कुछ समस्याएं देखी गई हैं और तय की गई हैं, खासकर #3720 में असेंबली-स्तरीय विशेषता आवेदन के संबंध में और हम अब 3.13.1 की प्रतीक्षा कर रहे हैं।

NUnit 3.13.1 जारी किया गया है।
कोई और मुद्दा बाकी है?

नहीं इसलिए इसे बंद कर दिया गया था @andrewlaser