Nunit: न्यू क्लोन के बाद nunit.framework.tests में विफल यूनिट टेस्ट

को निर्मित 25 जून 2018 · 31टिप्पणियाँ · स्रोत: nunit/nunit

मैंने अभी नूनिट का एक नया क्लोन पकड़ा है और विजुअल स्टूडियो 2017 (समुदाय 15.7.4) में समाधान को नवीनतम एनयूनीट 3 टेस्ट एडाप्टर (समानांतर में रन टेस्ट के साथ 3.10) के साथ विंडोज 10 प्रोफेशनल पर चल रहा है और "डीबग-एनीसीपीयू" चुना है। "और हिट बिल्ड।

BUILDING.md पढ़ने के बाद ऐसा लगता है कि मुझे किसी भी विफलता को अनदेखा करना चाहिए जो nunit.framework.tests-* और nunitlite.tests-* से नहीं आती है।

हालाँकि गेट के बाहर मुझे nunit.framework.tests-* से 2 विफलताएँ मिलती हैं

पहली त्रुटि:

Test Name:  TestCaseSourceCanAccessWorkDirectory("C:\\Users\\ace.olszowka\\source\\nunit\\bin\\Debug\\net20")
Test FullName:  NUnit.Framework.TestContextTests.TestCaseSourceCanAccessWorkDirectory("C:\\Users\\ace.olszowka\\source\\nunit\\bin\\Debug\\net20")
Test Source:    C:\Users\ace.olszowka\source\nunit\src\NUnitFramework\tests\TestContextTests.cs : line 110
Test Outcome:   Failed
Test Duration:  0:00:00.001

Result StackTrace:  at NUnit.Framework.TestContextTests.TestCaseSourceCanAccessWorkDirectory(String workDirectory) in C:\Users\ace.olszowka\source\nunit\src\NUnitFramework\tests\TestContextTests.cs:line 112
Result Message: 
Expected string length 34 but was 50. Strings differ at index 34.
  Expected: "C:\\Users\\ace.olszowka\\source\\nunit"
  But was:  "C:\\Users\\ace.olszowka\\source\\nunit\\bin\\Debug\\net20"
  -------------------------------------------------^

स्रोत को देखते हुए मुझे नहीं लगता कि यह कैसे संभव था, जहां तक मैं कह सकता हूं कि ये मान समान होना चाहिए ( _workDirectory और परीक्षण डेटा दोनों TestContext.CurrentContext.WorkDirectory ) मेरा एकमात्र अनुमान किसी प्रकार की दौड़ की स्थिति है, शायद मेरे अंत में खराब कॉन्फ़िगरेशन के कारण?

दूसरी त्रुटि:

Test Name:  StackTracesAreFiltered("WarningInBeginInvoke",4)
Test FullName:  NUnit.Framework.Assertions.WarningTests.StackTracesAreFiltered("WarningInBeginInvoke",4)
Test Source:    C:\Users\ace.olszowka\source\nunit\src\NUnitFramework\tests\Assertions\WarningTests.cs : line 292
Test Outcome:   Failed
Test Duration:  0:00:00.004

Result StackTrace:  at NUnit.Framework.Assertions.WarningTests.StackTracesAreFiltered(String methodName, Int32 maxLineCount) in C:\Users\ace.olszowka\source\nunit\src\NUnitFramework\tests\Assertions\WarningTests.cs:line 310
Result Message: 
Multiple failures or warnings in test:
  1) (Warning message)
  2) Expected the number of lines to be no more than 4, but it was 5:

 1. at NUnit.TestData.WarningFixture.<>c__DisplayClass45_0.<WarningInBeginInvoke>b__0()
 2. at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Object[]& outArgs)
 3. at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)
 4. at System.Runtime.Remoting.Proxies.AgileAsyncWorkerItem.ThreadPoolCallBack(Object o)
 5. at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
(end)

मैं इसमें खो गया हूँ कि यह परीक्षण यहाँ क्या करने का प्रयास कर रहा है; लेकिन मेरी सीमित समझ के आधार पर ऐसा लगता है कि यह कोड कॉल स्टैक में किसी भी बदलाव के प्रति वास्तव में संवेदनशील है, क्या यह .NET फ्रेमवर्क में हाल के बदलाव के कारण हो सकता है?

मुझे NUnitLite.Tests.CommandLineTests में विफल होने वाला प्रत्येक परीक्षण केस भी मिलता है यदि यह अप्रत्याशित है तो मुझे वहां खोदने में खुशी होगी।

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

bug normal

स्रोत

aolszowka

👍1

सभी 31 टिप्पणियाँ

रिपोर्ट के लिए धन्यवाद! मैंने पुष्टि की है कि TestCaseSourceCanAccessWorkDirectory और CommandLineTests टेस्ट एक्सप्लोरर में काम नहीं करते हैं। हमें उन्हें धावक और समानांतरवाद से स्वतंत्र बनाने के लिए एक रास्ता निकालने की जरूरत है। @ नूनिट/फ्रेमवर्क-टीम कोई विचार?

दूसरी त्रुटि के लिए, यह एक गंध परीक्षण है। इसे 5 तक टक्कर देना समझ में आता है।

jnm2 2 जुल॰ 2018

👍1

अतीत में, मैंने लोगों से कहा था कि वे NUnit परीक्षणों के लिए परीक्षण एक्सप्लोरर का उपयोग न करें। टीम के अन्य सदस्यों ने यह कहते हुए पीछे हट गए कि परीक्षण एक्सप्लोरर कई लोगों के लिए, परीक्षण चलाने का डिफ़ॉल्ट तरीका बन गया है।

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

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

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

निर्णय जो भी हो, मुझे लगता है कि आपको लोगों को वास्तविक NUnit धावकों (या तो NUnitLite या कंसोल रनर) को वापस भेजते रहना होगा, जब समस्याएँ आती हैं जो एडेप्टर के कारण हो सकती हैं या नहीं भी हो सकती हैं। एडेप्टर मूल रूप से तीसरे पक्ष के धावक के बराबर रहता है, भले ही वह एनयूनीट प्रोजेक्ट के तहत हो।

CharliePoole 2 जुल॰ 2018

👍1

एफडब्ल्यूआईडब्ल्यू बाहर से देख रहा है: यह वास्तव में मेरे लिए कोई फर्क नहीं पड़ता कि यह किस तरह से कटौती करता है जब तक कि इसका दस्तावेज इस तरह से हो।

बॉक्स के बाहर मैं एक डेवलपर के रूप में वह करने की कोशिश करूंगा जो मैं सामान्य रूप से करता हूं जब मुझे कोई नई परियोजना मिलती है जो उसी अभ्यास का उपयोग करती है जिसका मैं आंतरिक रूप से उपयोग करता हूं:

कोड क्लोन करें
पढ़ें README.md/BUILD.md/HACKING.md
बिल्ड का प्रयास करें (बिना बदलाव के)
यूनिट टेस्ट चलाएं (एकीकृत रनर के माध्यम से)।
अगर सब कुछ काम करता है तो सामान के साथ खेलना शुरू करें।

अतीत में यह रीशेर्पर का डॉटकवर रहा होगा, लेकिन हम इसे बंद करने की कोशिश कर रहे हैं क्योंकि लाइसेंसिंग लागत छोटी दुकानों/व्यक्तिगत डेवलपर्स के लिए पागल है जब फ्री/ओपन सोर्स सॉफ़्टवेयर विकल्प होते हैं जो "ज्यादातर काम करते हैं"।

एकीकृत विकास पर्यावरण अवधारणा में (मेरी राय में) बहुत कुछ है, वर्कफ़्लो से बाहर नहीं निकलना बहुत उपयोगी है, इसलिए हम ऐसा करते हैं।

हालांकि अगर हमें कंसोल रनर (या कुछ अन्य रनर) का उपयोग करने की उम्मीद है जो मेरे दिमाग में ठीक है, तो बस इसे दस्तावेज करें।

aolszowka 2 जुल॰ 2018

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

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

CharliePoole 2 जुल॰ 2018

हमें सभी फ्रेमवर्क परीक्षणों के लिए संभवतः NUnitLite के साथ CI कैननिकल बनाना चाहिए और फिर कंसोल, VSTest एडेप्टर और एंड-टू-एंड परीक्षणों के लिए UWP रनर बनाना चाहिए।

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

मौजूदा परीक्षणों का पता लगाएँ या नए परीक्षण लिखें
टाइप करते समय परीक्षणों को फिर से चलाने के लिए उस परीक्षण स्थिरता को पिन करें (और भी बेहतर, निरंतर परीक्षण शुरू करें)
एक बदलाव लागू करें
गिट कमिट बनाने से पहले, यह सुनिश्चित करने के लिए .\build.ps1 -t test चलाएँ कि पास और विफलताएँ अपेक्षित हैं
यदि कोई आश्चर्य है, तो उन प्रभावित परीक्षणों को ढूंढें और पिन करें जिनके बारे में मुझे नहीं पता था और चरण 3 पर जाएं

दुर्लभ परिदृश्य में जहां परीक्षण धावक-संवेदनशील होते हैं, मुझे यकीन नहीं है कि उन्हें धावक-असंवेदनशील बनाना चुनौतीपूर्ण है। यह ILMerge के लिए मेरे द्वारा लिखे गए एकीकरण परीक्षणों से भी बदतर नहीं हो सकता है, जिसे मैंने ReSharper और NCrunch छाया प्रतियों के लिए लचीला बनाया है।

jnm2 2 जुल॰ 2018

@aolszowka मैं आपकी बात से १००% सहमत हूं कि हम जो कुछ भी करते हैं, हमें योगदान दस्तावेज़ों का उपभोग करने में आसान और अद्यतित रखते हुए योगदानकर्ताओं के समय का सम्मान करना चाहिए।

jnm2 2 जुल॰ 2018

@ jnm2 मुझे आपका "विहित" दृष्टिकोण पसंद है। मुझे संदेह है कि टेस्ट एक्सप्लोरर में सब कुछ सुचारू रूप से काम करना आसान होगा, लेकिन यह कोशिश करने लायक है।

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

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

CharliePoole 2 जुल॰ 2018

👍1

यह मूल कारण हो सकता है। फ्रेमवर्क कंट्रोलर से एक्सएमएल प्राप्त करने के लिए परीक्षण लिखते समय, मैंने देखा कि TestContext.WorkDirectory को C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE बदला जा रहा था:

https://github.com/nunit/nunit/blob/81fcc7c047c09fcb5a86989d0829716ca7d08e1e/src/NUnitFramework/framework/Api/DefaultTestAssemblyBuilder.cs#L137

कॉल स्टैक:

>   nunit.framework.dll!NUnit.Framework.Api.DefaultTestAssemblyBuilder.Build(System.Reflection.Assembly assembly, string suiteName, System.Collections.Generic.IDictionary<string, object> options) Line 137    C#
    nunit.framework.dll!NUnit.Framework.Api.DefaultTestAssemblyBuilder.Build(string assemblyNameOrPath, System.Collections.Generic.IDictionary<string, object> options) Line 114    C#
    nunit.framework.dll!NUnit.Framework.Api.NUnitTestAssemblyRunner.Load(string assemblyNameOrPath, System.Collections.Generic.IDictionary<string, object> settings) Line 154   C#
    nunit.framework.dll!NUnit.Framework.Api.FrameworkController.LoadTests() Line 204    C#

ऐसा इसलिए है क्योंकि TestContext.WorkDirectory स्थिर परिवर्तनशील स्थिति है:

https://github.com/nunit/nunit/blob/81fcc7c047c09fcb5a86989d0829716ca7d08e1e/src/NUnitFramework/framework/TestContext.cs#L96 -L101

इसका मतलब है कि यह समवर्ती सहित सभी परीक्षणों (!) द्वारा साझा किया गया है। वर्कडायरेक्टरी पर निर्भर किसी भी परीक्षण को सही होने के लिए [NonParallelizable] चिह्नित किया जाना चाहिए।

jnm2 14 जुल॰ 2018

मैंने इस समस्या को बहुत समय पहले नोट किया था। इसे लेकर कहीं न कहीं विवाद है।

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

यह सब उस क्रम पर निर्भर करता है जिसमें परीक्षण निष्पादित किए जाते हैं, जो NUnit में अपरिभाषित है।

oznetmaster 14 जुल॰ 2018

इरादा यह है कि कार्य निर्देशिका को एक बार सेट किया जाना चाहिए और चलाने के लिए अपरिवर्तित रहना चाहिए। कुछ और यूएस एक बग।

CharliePoole 14 जुल॰ 2018

क्या कोई कारण है कि हम प्रत्येक निष्पादन संदर्भ के लिए एक स्वतंत्र कार्य निर्देशिका की अनुमति नहीं दे सकते हैं?

@CharliePoole हम इसे कैसे हकीकत बनाएंगे? हम एक विशेष स्थिति में हैं क्योंकि फ्रेमवर्क परीक्षण फ्रेमवर्क कंट्रोलर, एक नियंत्रक रन के भीतर चलने वाला नियंत्रक परीक्षण करता है।

jnm2 14 जुल॰ 2018

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

अपने स्वयं के परीक्षणों के लिए, हमें इसे सेट करने में सक्षम होने की आवश्यकता है, लेकिन अगर हम इसे सही करते हैं तो उस सेटिंग को अन्य परीक्षणों को प्रभावित नहीं करना चाहिए। हम शायद इसे सही नहीं कर रहे हैं। 😜

एक चुटकी में, हम इसे अपरिवर्तनीय बना सकते हैं और इसका परीक्षण बंद कर सकते हैं। <ducks>

CharliePoole 14 जुल॰ 2018

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

jnm2 14 जुल॰ 2018

ऐसे NUnit परीक्षण हैं जो इसे बदलते हैं, और यदि इसे अपरिवर्तनीय बनाया जाता है, तो वे विफल हो सकते हैं।

oznetmaster 14 जुल॰ 2018

@oznetmaster मैंने खोजा लेकिन कोई भी NUnit परीक्षण नहीं मिला जो इसे गलती से छोड़कर बदल देता है। क्या आपके पास कोई काम है?

jnm2 14 जुल॰ 2018

मुझे अपने अभिलेखागार खोजना होगा।

मैंने जो चर्चा की है उसे करके मैंने अपने CF बिल्ड में समस्या को पहले ही ठीक कर लिया है। केवल मान को एक बार सेट करने की अनुमति देता है। मैं इसे शून्य होने की जांच करता हूं, और यदि यह है, तो इसे सेट करने की अनुमति दें।

                if (options.ContainsKey (FrameworkPackageSettings.WorkDirectory))
                    TestContext.DefaultWorkDirectory = options[FrameworkPackageSettings.WorkDirectory] as string;
                else
                    if (TestContext.DefaultWorkDirectory == null)
                        TestContext.DefaultWorkDirectory = Directory.GetCurrentDirectory ();

oznetmaster 14 जुल॰ 2018

परीक्षण जो समस्या थे वे थे जो DefaultTestAssemblyBuilder.Build को उन विकल्पों के साथ कहते हैं जिनमें FrameworkPackageSettings.WorkDirectory शामिल नहीं है, जिससे TestContext.DefaultWorkDirectory को CurrentDirectory द्वारा अधिलेखित किया जा सकता है। इसका मतलब यह था कि अगर वर्कडायरेक्टरी को शीर्ष स्तर के निष्पादन में सेट किया गया था, तो इसे परीक्षण द्वारा अधिलेखित कर दिया जाएगा, और कभी भी बहाल नहीं किया जाएगा।

oznetmaster 14 जुल॰ 2018

ऐसा लगता है कि हम वही दृष्टिकोण अपनाना अच्छा होगा?

jnm2 14 जुल॰ 2018

मेरे लिये कार्य करता है। मेरा CF बिल्ड 100% NUnit परीक्षण पास करता है।

oznetmaster 14 जुल॰ 2018

👍1

@OmicronPersei यदि आप अगले कुछ दिनों में आस-पास हैं, तो क्या आप @oznetmaster को एक स्पिन

jnm2 14 जुल॰ 2018

हाँ! आज शाम कोशिश करेंगे

OmicronPersei 17 जुल॰ 2018

मैं वास्तव में इस बग को पुन: पेश नहीं कर सकता क्योंकि nunit3-vs-adapter#528 अन्य मुद्दों के कारण। विचार?

OmicronPersei 17 जुल॰ 2018

@OmicronPersei ओह। मुझे नहीं पता। क्या WorkDirectory सेट के साथ .runsettings का सही तरीके से उपयोग करना एक अच्छा समाधान होगा?

jnm2 17 जुल॰ 2018

ठीक है मैंने कोशिश की है। TestCaseSourceCanAccessWorkDirectory सफल होता है लेकिन StackTracesAreFiltered ओपी में एक ही संदेश/स्टैक ट्रेस के साथ विफल रहता है।

OmicronPersei 17 जुल॰ 2018

मुझे लगता है कि StackTracesAreFiltered को 5 से टकराया जाना चाहिए। यह एक गंध परीक्षण है ताकि हम नोटिस कर सकें कि क्या नए फ्रेम जोड़े गए हैं ताकि हम सुनिश्चित कर सकें कि यह नियंत्रण से बाहर नहीं हुआ है।

jnm2 17 जुल॰ 2018

TestCaseSourceCanAccessWorkDirectory बारे में क्या, या वह अभी भी इस पीआर के दायरे में है?

OmicronPersei 18 जुल॰ 2018

ForTestCaseCanAccessWorkDirectory, क्या @oznetmaster का समाधान इसे हल करता है? यदि नहीं, तो हमें आगे की जांच करनी होगी।

jnm2 18 जुल॰ 2018

मैं अपनी मशीन पर समस्या का पुनरुत्पादन नहीं कर सकता, प्रश्न में परीक्षण मेरे लिए गुजरता है।

OmicronPersei 20 जुल॰ 2018

कोई चिंता नहीं, कोई और वह हिस्सा कर सकता है मुझे छोटे पीआर भी पसंद हैं।

jnm2 20 जुल॰ 2018

बस घर की सफाई करने की कोशिश कर रहा हूँ; क्या कोई कारण है कि यह मुद्दा अभी भी खुला होना चाहिए या क्या हम इसे किसी प्रकार के संकल्प के साथ बंद कर सकते हैं? (भले ही यह WONTFIX हो)।

aolszowka 14 मई 2019

👍1

नहीं, इसे इंगित करने के लिए धन्यवाद। समापन।

rprouse 14 मई 2019

👍1

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Nunit: न्यू क्लोन के बाद nunit.framework.tests में विफल यूनिट टेस्ट

सभी 31 टिप्पणियाँ

संबंधित मुद्दों