Nunit: Arbeitsverzeichnis für Tests in Konsole NUnit 3

Dies ist beabsichtigt, wie hier gezeigt: https://github.com/nunit/nunit/wiki/Breaking-Changes

In früheren Versionen hat NUnit das Arbeitsverzeichnis geändert. Das tut es nicht mehr. Sie können TestContext.TestDirectory verwenden, um das Verzeichnis abzurufen, das die Testassembly enthält.

Neue URL: https://github.com/nunit/docs/wiki/Breaking-Changes

Das bricht viele Tests! Warum hast du das geändert? Einige der Tests können nicht behoben werden, da der Laufzeitcode der getesteten App davon abhängig war, dass das Arbeitsverzeichnis der Speicherort der Testassembly ist.

@imakowski haben Sie versucht, das aktuelle Arbeitsverzeichnis in einem Assembly-Setup auf ein bekanntes Verzeichnis zu setzen? Ungetesteter Code, aber so etwas wie;

``` C#
[SetUpFixture]
öffentliche Klasse MySetUpClass
{
[OneTimeSetUp]
RunBeforeAnyTests()
{
var dir = Path.GetDirectoryName(typeof(MySetUpClass).Assembly.Location);
Environment.CurrentDirectory = dir;

    // or
    Directory.SetCurrentDirectory(dir);
}

}
```

@imakowski Sie haben möglicherweise keine Kontrolle darüber, aber Code/Anwendungen sollten sich nicht darauf verlassen, dass das aktuelle Arbeitsverzeichnis festgelegt ist. Anwendungen sollten ihr bin-Verzeichnis immer mit Code bestimmen, wie ich ihn oben vorgestellt habe. Es gibt mehrere API-Aufrufe in Windows, die das aktuelle Arbeitsverzeichnis ändern, ohne dass Sie sich dessen bewusst sind. Ihre Anwendung kann die meiste Zeit problemlos ausgeführt werden, schlägt dann jedoch fehl, wenn ein Benutzer einen selten verwendeten Teil Ihrer Anwendung besucht.

@rprouse dieser Code funktioniert nicht, wenn er sich im Schattenkopiemodus befindet
var dir = Path.GetDirectoryName(typeof(MySetUpClass).Assembly.Location);

Sie könnten dies in diesem Fall verwenden:
var dir = Path.GetDirectoryName(new Uri(typeof(MySetUpClass).Assembly.CodeBase).LocalPath);

Alternativ stellen wir es Ihnen als TestContext.CurrentContext.TestDirectory zur Verfügung. :-)

Wir verwenden die Uri wie vorgeschlagen mit einigen Anpassungen für spezielle Fälle.

Alternativ stellen wir es Ihnen als TestContext.CurrentContext.TestDirectory zur Verfügung. :-)

In CurrentContext gibt es keine TestDirectory-Eigenschaft mehr. ich benutze nunit 3.6.1. Es gibt nur WorkDirectory, das in meinem Fall, wenn ich den Test von Resharper-Punkten an die falsche Stelle starte:(

Es gibt TestContext.TestDirectory. Es ist eine statische Eigenschaft. Ich glaube, dass WorkDirectory auch so ist?

Nun, ich kann es weder mit dem Visual Studio-Browser noch mit dem Compiler oder dem Teleric-Decompiler finden.
aber ich sehe es in Nunit 3.5. nicht sicher was los ist

Ich lag falsch.

Es ist TestContext.CurrentContext.TestDirectory.

Es ist jedoch nicht auf dem PORTABLE-Build vorhanden.

#if !PORTABLE
        /// <summary>
        /// Gets the directory containing the current test assembly.
        /// </summary>
        public string TestDirectory
        {
            get
            {
                Assembly assembly = _testExecutionContext?.CurrentTest?.TypeInfo?.Assembly;

                if (assembly != null)
                    return AssemblyHelper.GetDirectoryName(assembly);

#if NETSTANDARD1_6
                // Test is null, we may be loading tests rather than executing.
                // Assume that the NUnit framework is in the same directory as the tests
                return AssemblyHelper.GetDirectoryName(typeof(TestContext).GetTypeInfo().Assembly);
#else
                // Test is null, we may be loading tests rather than executing.
                // Assume that calling assembly is the test assembly.
                return AssemblyHelper.GetDirectoryName(Assembly.GetCallingAssembly());
#endif
            }
        }
#endif

es ist in 3.6.0 vorhanden, aber nicht in 3.6.1

Ich schaue mir das aktuelle Github-Repository an und es ist genau so, wie ich es oben kopiert und eingefügt habe.

Sind Sie sicher, dass Sie den PORTABLE-Build irgendwie nicht verwenden?

ja, ich benutze es

Nun, deshalb ist es nicht da. Es wird im PORTABLE-Build nicht unterstützt und wurde meines Wissens auch nie unterstützt. Ich habe den PORTABLE-Build jedoch noch nie verwendet, sondern einfach die CI-Tests damit ausgeführt.

Danke schön

Directory.SetCurrentDirectory(AppDomain.CurrentDomain.BaseDirectory);

Für Leute, die nach echtem Code @CharliePoole und @rprouse gesagt haben, ist es

[SetUpFixture]
public class MySetUpClass
{
    [OneTimeSetUp]
    public void RunBeforeAnyTests()
    {
        Environment.CurrentDirectory = TestContext.CurrentContext.TestDirectory;
        // or identically under the hoods
        Directory.SetCurrentDirectory(TestContext.CurrentContext.TestDirectory);
    }
}

Für globale Initialisierung

Schließen Sie die obige Logik nur nicht in einen Namespace ein. dh

using NUnit.Framework;
using System;
using System.IO;

[SetUpFixture]
public class GlobalSetup
{
    [OneTimeSetUp]
    public void RunBeforeAnyTests()
    {
        Environment.CurrentDirectory = TestContext.CurrentContext.TestDirectory;
        // or identically under the hoods
        Directory.SetCurrentDirectory(TestContext.CurrentContext.TestDirectory);
    }
}

Außerdem scheint das TestContext.CurrentContext.TestDirectory etwas mehr Intelligenz zu haben, um Eckfälle anzugehen, also würde ich das über typeof(MySetUpClass).Assembly.Location wählen

also würde ich das über typeof(MySetUpClass).Assembly.Location wählen

Location gibt die Schattenposition zurück, wenn die Assembly schattenkopiert wird, normalerweise möchten Sie das nicht. Verwenden Sie stattdessen CodeBase , wodurch ein Uri des tatsächlichen Standorts zurückgegeben wird, von dem aus es ursprünglich ausgeführt wurde, bevor Schattenkopien erstellt werden.

Offensichtlich ist es besser, TestDirectory , aber es scheint Probleme mit dieser Eigenschaft zu geben, siehe #2872, die Ausnahmen verursachen, die nicht abgefangen werden können. Ich weiß nicht, ob sie auch erscheinen können, wenn Sie OneTimeSetup (ich nehme an, nicht), aber es sollte darauf geachtet werden, bis dies behoben ist.