निर्धारित करें कि क्या कोड एक इकाई परीक्षण के भाग के रूप में चल रहा है

Question

मेरा एक यूनिट टेस्ट (nUnit) है। एक इकाई परीक्षण के माध्यम से चल रहा है, तो कॉल स्टैक नीचे कई परतें एक विधि विफल हो जाएंगी।

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

मैं सेटअप nUnit विशिष्ट तरीके नहीं चाहता - यहाँ बहुत सारे स्तर हैं और इसकी इकाई परीक्षण करने का एक खराब तरीका है।

इसके बजाय मैं जो करना चाहूंगा, वह कॉल स्टैक में कुछ इस तरह से जोड़ना है

#IF DEBUG // Unit tests only included in debug build
if (IsRunningInUnitTest)
   {
   // Do some setup to avoid error
   }
#endif

तो IsRunningInUnitTest लिखने के बारे में कोई विचार?

पीएस मैं पूरी तरह से अवगत हूं कि यह महान डिजाइन नहीं है, लेकिन मुझे लगता है कि इसके विकल्पों से बेहतर है।

Comments

आपको यूनिट टेस्ट में प्रत्यक्ष या अप्रत्यक्ष रूप से तीसरे पक्ष के कोड का परीक्षण नहीं करना चाहिए। आपको तृतीय-पक्ष कार्यान्वयन से परीक्षण के तहत अपने तरीके को अलग करना चाहिए।

— क्रेग स्टंट ज़ूल

हां - मुझे लगता है कि - एक विचार की दुनिया में, लेकिन कभी-कभी हमें चीजों के बारे में थोड़ा व्यावहारिक होना चाहिए?

— रयान

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

— रयान

रयान, आप तीसरे पक्ष के व्यवहार के बारे में मान्यताओं का परीक्षण कर सकते हैं, लेकिन यह एक अलग परीक्षा है। आपको अलगाव में अपने स्वयं के कोड का परीक्षण करने की आवश्यकता है।

— क्रेग स्टंट ज़ूल

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

— रयान

Answer 1

मैंने ऐसा पहले भी किया है - मैंने ऐसा करते समय अपनी नाक पकड़ रखी थी, लेकिन मैंने ऐसा किया। व्यावहारिकता हर बार हठधर्मिता को हरा देती है। बेशक, अगर वहाँ है एक अच्छा तरीका आप इसे से बचने के लिए refactor कर सकते हैं, कि बहुत अच्छा होगा।

मूल रूप से मेरे पास एक "UnitTestDetector" वर्ग था, जिसने यह जाँच की थी कि वर्तमान AppDain में NUnit फ्रेमवर्क असेंबली भरी हुई थी या नहीं। इसे केवल एक बार करने की आवश्यकता है, फिर परिणाम को कैश करें। बदसूरत, लेकिन सरल और प्रभावी।

Comments

UnitTestDetector के बारे में कोई नमूना? और MSTest के लिए समान?

— किनिकेत

@Kiquenet: मुझे लगता है कि मैं सिर्फ AppDomain.GetAssembliesसंबंधित विधानसभा के लिए उपयोग और जांच करूंगा - MSTest के लिए आपको यह देखना होगा कि कौन सी विधानसभाएं भरी हुई हैं। एक उदाहरण के लिए रयान के जवाब को देखें।

— जॉन स्कीट

यह मेरे लिए अच्छा तरीका नहीं है। मैं एक कंसोल ऐप से एक यूनिटटेस्ट विधि कह रहा हूं और यह सोचता है कि यह एक यूनिटटेस्ट ऐप है।

— बिशन

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

— जॉन स्कीट

Answer 2

जॉन के विचार को लेते हुए कि मैं क्या कर रहा हूँ -

using System;
using System.Reflection;

/// <summary>
/// Detect if we are running as part of a nUnit unit test.
/// This is DIRTY and should only be used if absolutely necessary 
/// as its usually a sign of bad design.
/// </summary>    
static class UnitTestDetector
{

    private static bool _runningFromNUnit = false;      

    static UnitTestDetector()
    {
        foreach (Assembly assem in AppDomain.CurrentDomain.GetAssemblies())
        {
            // Can't do something like this as it will load the nUnit assembly
            // if (assem == typeof(NUnit.Framework.Assert))

            if (assem.FullName.ToLowerInvariant().StartsWith("nunit.framework"))
            {
                _runningFromNUnit = true;
                break;
            }
        }
    }

    public static bool IsRunningFromNUnit
    {
        get { return _runningFromNUnit; }
    }
}

पीछे की ओर पाइप करें हम सभी बड़े लड़के हैं पहचानने के लिए जब हम कुछ ऐसा कर रहे हैं जो हमें शायद नहीं करना चाहिए;)

Comments

+1 अच्छा जवाब। इसे हालांकि थोड़ा सा सरल बनाया जा सकता है, नीचे देखें: stackoverflow.com/a/30356080/184528

— cdiggins

जिस विशेष परियोजना के लिए मैंने यह लिखा था वह थी (और अभी भी है!) .NET 2.0 इसलिए कोई linq नहीं है।

— रेयान

यह मेरे लिए काम करने के लिए उपयोग करता है, लेकिन ऐसा लगता है जैसे विधानसभा का नाम बदल गया है। मैंने Kiquenet के समाधान पर

— The_Black_Smurf

मुझे ट्रैविस

— सीई

मेरे लिए काम करता है, मुझे razor के साथ .NET कोर 3 बग को हैक करना पड़ता है जो केवल यूनिट परीक्षणों में होता है।

— jjxtra

Answer 3

रयान के उत्तर से अनुकूलित। यह एक एमएस इकाई परीक्षण ढांचे के लिए है।

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

/// <summary>
/// Detects if we are running inside a unit test.
/// </summary>
public static class UnitTestDetector
{
    static UnitTestDetector()
    {
        string testAssemblyName = "Microsoft.VisualStudio.QualityTools.UnitTestFramework";
        UnitTestDetector.IsInUnitTest = AppDomain.CurrentDomain.GetAssemblies()
            .Any(a => a.FullName.StartsWith(testAssemblyName));
    }

    public static bool IsInUnitTest { get; private set; }
}

और यहाँ इसके लिए एक इकाई परीक्षण है:

    [TestMethod]
    public void IsInUnitTest()
    {
        Assert.IsTrue(UnitTestDetector.IsInUnitTest, 
            "Should detect that we are running inside a unit test."); // lol
    }

Comments

मेरे पास एक बेहतर तरीका है जो आपके MessageBox समस्या को हल करता है और इस हैक को रोकता है और अधिक यूनिट परीक्षण मामलों को वितरित करता है। मैं एक वर्ग का उपयोग करता हूं जो एक इंटरफ़ेस लागू करता है जिसे मैं ICommonDialogs कहता हूं। कार्यान्वयन वर्ग सभी पॉप अप संवाद (संदेश बॉक्स, फ़ाइल संवाद, रंग बीनने वाला, डेटाबेस कनेक्शन संवाद आदि) प्रदर्शित करता है। संदेश बक्से प्रदर्शित करने की आवश्यकता वाली कक्षाएं एक निर्माण पैरामीटर के रूप में ICommonDiaglogs को स्वीकार करती हैं जिन्हें हम इकाई परीक्षण में मॉक कर सकते हैं। बोनस: आप अपेक्षित MessageBox कॉल पर जोर दे सकते हैं।

— टोनी ओ'हागन

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

— डैन-जीएफ

गंभीरता से, लोग, निर्भरता इंजेक्शन के बारे में सीखते हैं, और दूसरी बात, मॉक ऑब्जेक्ट। निर्भरता इंजेक्शन आपकी प्रोग्रामिंग में क्रांति लाएगा।

— डैन-जीएफ

मैं UnitTestDetector.IsInUnitTest को "वापसी सच" के रूप में लागू करूंगा और आपकी इकाई परीक्षा पास होगी। ;) उन अजीब चीजों में से एक जो इकाई परीक्षण के लिए असंभव लगता है।

— समीर आद्रा

Microsoft.VisualStudio.QualityTools.UnitTestFramework अब मेरे लिए काम नहीं करता था। इसे Microsoft.VisualStudio.TestPlatform.TestFramework में बदल दिया - जो फिर से काम करता है।

— अलेक्जेंडर

Answer 4

रयान के समाधान को सरल करते हुए, आप निम्न स्थिर संपत्ति को किसी भी वर्ग में जोड़ सकते हैं:

    public static readonly bool IsRunningFromNUnit = 
        AppDomain.CurrentDomain.GetAssemblies().Any(
            a => a.FullName.ToLowerInvariant().StartsWith("nunit.framework"));

Comments

डैन-जीएफ के जवाब के रूप में बहुत ही सुंदर (हालांकि यह वीएस टूलसेट की तलाश में था, ननिट नहीं)।

— रयान

Answer 5

मैं तालसथ के समान दृष्टिकोण का उपयोग करता हूं

यह मूल कोड है जिसे कैशिंग शामिल करने के लिए आसानी से संशोधित किया जा सकता है। एक और अच्छा विचार कोड निष्पादन से बचने के लिए अपनी परियोजनाओं के मुख्य प्रवेश बिंदु पर एक सेटर जोड़ना IsRunningInUnitTestऔर कॉल UnitTestDetector.IsRunningInUnitTest = falseकरना होगा।

public static class UnitTestDetector
{
    public static readonly HashSet<string> UnitTestAttributes = new HashSet<string> 
    {
        "Microsoft.VisualStudio.TestTools.UnitTesting.TestClassAttribute",
        "NUnit.Framework.TestFixtureAttribute",
    };
    public static bool IsRunningInUnitTest
    {
        get
        {
            foreach (var f in new StackTrace().GetFrames())
                if (f.GetMethod().DeclaringType.GetCustomAttributes(false).Any(x => UnitTestAttributes.Contains(x.GetType().FullName)))
                    return true;
            return false;
        }
    }
}

Comments

मुझे यह दृष्टिकोण उच्च मतदान वाले उत्तर से अधिक पसंद है। मुझे नहीं लगता कि यह मानना ​​सुरक्षित है कि यूनिट टेस्ट असेंबली केवल एक यूनिट टेस्ट के दौरान भरी जाएगी और प्रक्रिया का नाम भी डेवलपर से डेवलपर तक भिन्न हो सकता है (उदाहरण। कुछ आर # टेस्ट धावक का उपयोग करें)।

— EM0

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

— सर्गेई

Answer 6

शायद उपयोगी, वर्तमान ProcessName की जाँच:

public static bool UnitTestMode
{
    get 
    { 
        string processName = System.Diagnostics.Process.GetCurrentProcess().ProcessName;

        return processName == "VSTestHost"
                || processName.StartsWith("vstest.executionengine") //it can be vstest.executionengine.x86 or vstest.executionengine.x86.clr20
                || processName.StartsWith("QTAgent");   //QTAgent32 or QTAgent32_35
    }
}

और इस फ़ंक्शन को भी unittest द्वारा जांचना चाहिए:

[TestClass]
public class TestUnittestRunning
{
    [TestMethod]
    public void UnitTestRunningTest()
    {
        Assert.IsTrue(MyTools.UnitTestMode);
    }
}

संदर्भ:
मैथ्यू वाटसन http://social.msdn.microsoft.com/Forums/en-US/csharplanguage/thread/11e68468-c95e-4c43-b02b-7045552b407e/ में

Comments

|| processName.StartsWith("testhost") // testhost.x86वीएस 2019 के लिए

— किकेनेट

Answer 7

टेस्ट मोड में, Assembly.GetEntryAssembly()लगता है null।

#IF DEBUG // Unit tests only included in debug build 
  if (Assembly.GetEntryAssembly() == null)    
  {
    // Do some setup to avoid error    
  }
#endif 

ध्यान दें कि अगर Assembly.GetEntryAssembly()है null, Assembly.GetExecutingAssembly()नहीं है।

प्रलेखन कहते हैं: GetEntryAssemblyविधि लौट सकते हैं nullजब विधानसभा में कामयाब एक एक अप्रबंधित आवेदन से लोड किया गया है।

Answer 8

परियोजना में कहीं परीक्षण किया जा रहा है:

public static class Startup
{
    public static bool IsRunningInUnitTest { get; set; }
}

आपकी इकाई परीक्षण परियोजना में कहीं:

[TestClass]
public static class AssemblyInitializer
{
    [AssemblyInitialize]
    public static void Initialize(TestContext context)
    {
        Startup.IsRunningInUnitTest = true;
    }
}

सुरुचिपूर्ण, नहीं। लेकिन सीधा और तेज। AssemblyInitializerएमएस टेस्ट के लिए है। मुझे उम्मीद है कि अन्य परीक्षण रूपरेखाएँ समतुल्य होंगी।

Comments

यदि आपके द्वारा परीक्षण किया जा रहा कोड अतिरिक्त AppDomains बनाता है, IsRunningInUnitTestतो उन AppDomains में सही पर सेट नहीं होता है।

— एडवर्ड ब्रे

लेकिन एक साझा असेंबली को जोड़कर या प्रत्येक डोमेन में IsRunningInUnitTest घोषित करके इसे आसानी से हल किया जा सकता है ।

— सेर्गेई

Answer 9

मैं इसे केवल स्किप करने वाले तर्क के लिए उपयोग करता हूं, जो स्टार्टअप के दौरान log4net में सभी TraceAppenders को निष्क्रिय करता है जब कोई डिबगर संलग्न नहीं होता है। यह यूनिट टेस्ट को गैर-डीबग मोड में चलने पर भी Resharper परिणाम विंडो में लॉग इन करने की अनुमति देता है।

इस फ़ंक्शन का उपयोग करने वाली विधि को या तो एप्लिकेशन के स्टार्टअप पर या टेस्ट फिचर शुरू करने पर बुलाया जाता है।

यह रयान के पद के समान है, लेकिन LINQ का उपयोग करता है, System.Reflection आवश्यकता को ड्रॉप करता है, परिणाम कैश नहीं करता है, और (आकस्मिक) दुरुपयोग को रोकने के लिए निजी है।

    private static bool IsNUnitRunning()
    {
        return AppDomain.CurrentDomain.GetAssemblies().Any(assembly => assembly.FullName.ToLowerInvariant().StartsWith("nunit.framework"));
    }

Answer 10

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

ननिट असेंबली के लिए जाँच करने के बजाय, हम जाँच करने के लिए ननित आपी से पूछ सकते हैं कि अभी परीक्षण निष्पादित करने के तहत कोड है या नहीं।

using NUnit.Framework;

// ...

if (TestContext.CurrentContext != null)
{
    // nunit test detected
    // Do some setup to avoid error
}

संपादित करें:

यदि आवश्यक हो तो TestContext स्वतः उत्पन्न हो सकता है।

Comments

कृपया यहाँ कोड डंप न करें। समझाइए कि यह क्या करता है।

— nkr

Answer 11

बस इस का उपयोग करें:

AppDomain.CurrentDomain.IsDefaultAppDomain()

परीक्षण मोड में, यह गलत वापस आ जाएगा।

Answer 12

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

internal abstract class TestModeDetector
{
    internal abstract bool RunningInUnitTest();

    internal static TestModeDetector GetInstance()
    {
    #if DEBUG
        return new DebugImplementation();
    #else
        return new ReleaseImplementation();
    #endif
    }

    private class ReleaseImplementation : TestModeDetector
    {
        internal override bool RunningInUnitTest()
        {
            return false;
        }
    }

    private class DebugImplementation : TestModeDetector
    {
        private Mode mode_;

        internal override bool RunningInUnitTest()
        {
            if (mode_ == Mode.Unknown)
            {
                mode_ = DetectMode();
            }

            return mode_ == Mode.Test;
        }

        private Mode DetectMode()
        {
            return HasUnitTestInStack(new StackTrace()) ? Mode.Test : Mode.Regular;
        }

        private static bool HasUnitTestInStack(StackTrace callStack)
        {
            return GetStackFrames(callStack).SelectMany(stackFrame => stackFrame.GetMethod().GetCustomAttributes(false)).Any(NunitAttribute);
        }

        private static IEnumerable<StackFrame> GetStackFrames(StackTrace callStack)
        {
            return callStack.GetFrames() ?? new StackFrame[0];
        }

        private static bool NunitAttribute(object attr)
        {
            var type = attr.GetType();
            if (type.FullName != null)
            {
                return type.FullName.StartsWith("nunit.framework", StringComparison.OrdinalIgnoreCase);
            }
            return false;
        }

        private enum Mode
        {
            Unknown,
            Test,
            Regular
        }

Comments

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

— पैट्रिक एम

Answer 13

एक जादू की तरह काम करता है

if (AppDomain.CurrentDomain.GetAssemblies().FirstOrDefault(x => x.FullName.ToLowerInvariant().StartsWith("nunit.framework")) != null)
{
    fileName = @"C:\Users\blabla\xxx.txt";
}
else
{
    var sfd = new SaveFileDialog
    {     ...     };
    var dialogResult = sfd.ShowDialog();
    if (dialogResult != DialogResult.OK)
        return;
    fileName = sfd.FileName;
}

।

Answer 14

यूनिट परीक्षण आवेदन प्रविष्टि बिंदु को छोड़ देगा। कम से कम wpf, winforms और कंसोल एप्लिकेशन main()को नहीं बुलाया जा रहा है।

मुख्य विधि की तुलना में कहा जाता है अगर हम में हैं चलाने के समय , अन्यथा हम में हैं इकाई परीक्षण मोड:

public static bool IsUnitTest { get; private set; } = true;

[STAThread]
public static void main()
{
    IsUnitTest = false;
    ...
}

Answer 15

अपने कोड को ध्यान में रखते हुए एक विंडोज़ के मुख्य (गुई) धागे में सामान्य रूप से चलाया जाता है और आप यह चाहते हैं कि परीक्षण में दौड़ते समय आप अलग व्यवहार कर सकें

if (SynchronizationContext.Current == null)
{
    // code running in a background thread or from within a unit test
    DoSomething();
}
else
{
    // code running in the main thread or any other thread where
    // a SynchronizationContext has been set with
    // SynchronizationContext.SetSynchronizationContext(synchronizationContext);
    DoSomethingAsync();
}

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

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

ज्ञात रहे कि यह Determine if code is running as part of a unit testओपी के अनुरोध के अनुसार एक विश्वसनीय तरीका नहीं है क्योंकि कोड एक थ्रेड के अंदर चल सकता है, लेकिन कुछ परिदृश्यों के लिए यह एक अच्छा समाधान हो सकता है (यह भी: यदि मैं पहले से ही एक बैकग्राउंड थ्रेड से चल रहा हूं, तो यह आवश्यक नहीं हो सकता है एक नई शुरुआत करने के लिए)।

Answer 16

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

Answer 17

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

    If Not Application.ProductName.ToLower().Contains("test") then
        ' Do something 
    End If

Answer 18

प्रतिबिंब और कुछ इस तरह का उपयोग करने के बारे में कैसे:

var underTest = Assembly.GetCallingAssembly ()! = typeof (MainForm) .Assembly;

कॉलिंग असेंबली वह जगह होगी जहां आपके परीक्षण के मामले हैं और मेनफ़ॉर्म के विकल्प के रूप में कुछ प्रकार आपके कोड में परीक्षण किया जा रहा है।

Answer 19

जब आप कक्षा का परीक्षण कर रहे हों तो वास्तव में एक सरल उपाय है ...

बस उस वर्ग को दें जो आप इस तरह से एक संपत्ति का परीक्षण कर रहे हैं:

// For testing purposes to avoid running certain code in unit tests.
public bool thisIsUnitTest { get; set; }

अब आपका यूनिट टेस्ट "thisIsUnitTest" बूलियन को सच करने के लिए सेट कर सकता है, इसलिए कोड में जिसे आप छोड़ना चाहते हैं, जोड़ें:

   if (thisIsUnitTest)
   {
       return;
   } 

असेंबली का निरीक्षण करने की तुलना में इसका आसान और तेज़ है। रूबी ऑन रेल्स की याद दिलाता है जहाँ आप देखना चाहते हैं कि क्या आप टेस्ट के माहौल में हैं।

Comments

मुझे लगता है कि आप यहां नीचे मतदान कर रहे थे क्योंकि आप कक्षा के व्यवहार को संशोधित करने के लिए परीक्षण पर ही भरोसा कर रहे हैं।

— रिगार्ड्ट स्टेन

यह यहाँ के अन्य सभी उत्तरों से अधिक बुरा नहीं है।

— डोनो