Sprawdź, czy kod jest uruchomiony w ramach testu jednostkowego

Mam test jednostkowy (nUnit). Wiele warstw w dół stosu wywołań metoda zakończy się niepowodzeniem, jeśli zostanie uruchomiona za pośrednictwem testu jednostkowego.

Idealnie byłoby użyć czegoś takiego jak mockowanie do skonfigurowania obiektu, od którego zależy ta metoda, ale jest to kod innej firmy i nie mogę tego zrobić bez dużego nakładu pracy.

Nie chcę konfigurować metod specyficznych dla nUnit - jest tu zbyt wiele poziomów i jest to kiepski sposób wykonywania testów jednostkowych.

Zamiast tego chciałbym dodać coś takiego głęboko w stosie wywołań

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

Więc jakieś pomysły na to, jak napisać IsRunningInUnitTest?

PS Jestem w pełni świadomy, że to nie jest świetny projekt, ale myślę, że jest lepszy niż alternatywy.

Robiłem to już wcześniej - musiałem trzymać nos, kiedy to robiłem, ale zrobiłem to. Pragmatyzm za każdym razem bije dogmatyzm. Oczywiście, jeśli nie jest to sposób miły byłaby można go uniknąć, że byłoby świetnie.

Zasadniczo miałem klasę „UnitTestDetector”, która sprawdzała, czy zestaw struktury NUnit został załadowany do bieżącej domeny AppDomain. Wystarczyło to zrobić tylko raz, a następnie zapisać wynik w pamięci podręcznej. Brzydki, ale prosty i skuteczny.

Biorąc pomysł Jona, oto co wymyśliłem -

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; }
    }
}

Z tyłu, wszyscy jesteśmy na tyle duzi, chłopcy, żeby rozpoznać, kiedy robimy coś, czego prawdopodobnie nie powinniśmy;)

Na podstawie odpowiedzi Ryana. Ten jest przeznaczony dla platformy testów jednostkowych MS.

Powodem tego jest to, że pokazuję MessageBox przy błędach. Ale moje testy jednostkowe testują również kod obsługi błędów i nie chcę, aby MessageBox pojawiał się podczas uruchamiania testów jednostkowych.

/// <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; }
}

A oto test jednostkowy:

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

Upraszczając rozwiązanie Ryana, możesz po prostu dodać następującą właściwość statyczną do dowolnej klasy:

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

Stosuję podobne podejście jak tallseth

Jest to podstawowy kod, który można łatwo zmodyfikować, aby uwzględnić buforowanie. Innym dobrym pomysłem byłoby dodanie metody ustawiającej IsRunningInUnitTesti wywołanie UnitTestDetector.IsRunningInUnitTest = falsegłównego punktu wejścia projektu, aby uniknąć wykonywania kodu.

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;
        }
    }
}

Może przydatne, sprawdzając bieżącą nazwę procesu:

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
    }
}

I tę funkcję należy również sprawdzić przez unittest:

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

Źródła:
Matthew Watson w http://social.msdn.microsoft.com/Forums/en-US/csharplanguage/thread/11e68468-c95e-4c43-b02b-7045a52b407e/

W trybie testowym Assembly.GetEntryAssembly()wydaje się , że tak null.

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

Zauważ, że jeśli Assembly.GetEntryAssembly()tak null, Assembly.GetExecutingAssembly()nie jest.

Dokumentacja mówi: the GetEntryAssemblymetoda może powrócić null, gdy udało montaż został załadowany z niezarządzanych aplikacji.

Gdzieś w testowanym projekcie:

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

Gdzieś w projekcie testów jednostkowych:

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

Elegancki, nie. Ale prosto i szybko. AssemblyInitializerdotyczy testu MS. Spodziewałbym się, że inne ramy testowe będą miały odpowiedniki.

Używam tego tylko do pomijania logiki, która wyłącza wszystkie TraceAppender w log4net podczas uruchamiania, gdy nie jest podłączony debugger. Dzięki temu testy jednostkowe mogą logować się do okna wyników Resharper, nawet jeśli działają w trybie innym niż debugowanie.

Metoda używająca tej funkcji jest wywoływana podczas uruchamiania aplikacji lub podczas uruchamiania urządzenia testowego.

Jest podobny do postu Ryana, ale używa LINQ, odrzuca wymóg System.Reflection, nie buforuje wyniku i jest prywatny, aby zapobiec (przypadkowemu) nadużyciu.

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

Odniesienie do frameworka nunit nie oznacza, że ​​test faktycznie działa. Na przykład w Unity, gdy aktywujesz testy w trybie odtwarzania, odniesienia nunit są dodawane do projektu. A kiedy uruchamiasz grę, odniesienia istnieją, więc UnitTestDetector nie działałby poprawnie.

Zamiast sprawdzać, czy nunit jest asemblowany, możemy poprosić nunit api o sprawdzenie, czy kod jest w trakcie wykonywania testu, czy nie.

using NUnit.Framework;

// ...

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

Edytować:

Uważaj, jeśli jest to wymagane, kontekst testowy może zostać wygenerowany automatycznie .

Po prostu użyj tego:

AppDomain.CurrentDomain.IsDefaultAppDomain()

W trybie testowym zwróci fałsz.

Niedawno byłem niezadowolony z tego problemu. Rozwiązałem to w nieco inny sposób. Po pierwsze, nie chciałem zakładać, że framework nunit nigdy nie zostanie załadowany poza środowiskiem testowym; Szczególnie martwiłem się, że programiści uruchamiają aplikację na swoich komputerach. Więc zamiast tego przeszedłem przez stos wywołań. Po drugie, byłem w stanie założyć, że kod testowy nigdy nie zostanie uruchomiony na plikach binarnych wydania, więc upewniłem się, że ten kod nie istnieje w systemie wydania.

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
        }

działa jak marzenie

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;
}

.

Testy jednostkowe pominą punkt wejścia aplikacji. Przynajmniej dla wpf, winforms i aplikacja konsolowa main()nie są wywoływane.

Jeśli wywoływana jest metoda główna, to jesteśmy w czasie wykonywania , w przeciwnym razie jesteśmy w trybie testu jednostkowego :

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

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

Biorąc pod uwagę, że twój kod jest normalnie uruchamiany w głównym wątku (gui) aplikacji formularzy systemu Windows i chcesz, aby zachowywał się inaczej podczas uruchamiania w teście, możesz sprawdzić

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();
}

Używam tego do kodu, który chcę fire and forgotw aplikacji GUI, ale w testach jednostkowych mogę potrzebować obliczonego wyniku dla potwierdzenia i nie chcę zadzierać z wieloma uruchomionymi wątkami.

Działa dla MSTest. Zaletą jest to, że mój kod nie musi sprawdzać samej struktury testowej i jeśli naprawdę potrzebuję zachowania asynchronicznego w pewnym teście, mogę ustawić własny SynchronizationContext.

Należy pamiętać, że nie jest to niezawodna metoda Determine if code is running as part of a unit testzgodnie z żądaniem OP, ponieważ kod może działać wewnątrz wątku, ale w niektórych scenariuszach może to być dobre rozwiązanie (również: jeśli już pracuję z wątku w tle, może to nie być konieczne rozpocząć nowy).

Application.Current ma wartość null, gdy działa w ramach testera jednostkowego. Przynajmniej dla mojej aplikacji WPF przy użyciu testera MS Unit. W razie potrzeby to łatwy test. Warto też pamiętać o używaniu Application.Current w kodzie.

Użyłem poniższego w VB w moim kodzie, aby sprawdzić, czy jesteśmy w teście jednostkowym. w szczególności nie chciałem, aby test otwierał Worda

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

Co powiesz na użycie refleksji i coś takiego:

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

Zestaw wywołujący będzie tam, gdzie są twoje przypadki testowe i po prostu zastąp MainForm jakiś typ, który jest w testowanym kodzie.

Jest też naprawdę proste rozwiązanie, gdy testujesz klasę ...

Po prostu podaj klasę, dla której testujesz, taką właściwość:

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

Teraz twój test jednostkowy może ustawić wartość logiczną „thisIsUnitTest” na true, więc w kodzie, który chcesz pominąć, dodaj:

   if (thisIsUnitTest)
   {
       return;
   } 

Jest to łatwiejsze i szybsze niż przeglądanie zespołów. Przypomina mi Ruby On Rails, w którym chciałbyś sprawdzić, czy jesteś w środowisku TEST.