Nunit: Рабочий каталог для тестов в консоли NUnit 3

Это сделано намеренно, как показано здесь: https://github.com/nunit/nunit/wiki/Breaking-Changes

В более ранних версиях NUnit менял рабочий каталог. Это больше не так. Вы можете использовать TestContext.TestDirectory, чтобы получить каталог, содержащий тестовую сборку.

Новый URL: https://github.com/nunit/docs/wiki/Breaking-Changes

Это ломает много испытаний! Почему ты это изменил? Некоторые тесты не могут быть исправлены, потому что код времени выполнения тестируемого приложения зависел от того, что рабочий каталог является местоположением тестовой сборки.

@imakowski вы пытались установить текущий рабочий каталог в известный каталог в настройке сборки? Непроверенный код, но что-то вроде:

`` С #
[SetUpFixture]
открытый класс MySetUpClass
{
[OneTimeSetUp]
RunBeforeAnyTests ()
{
var dir = Path.GetDirectoryName (typeof (MySetUpClass) .Assembly.Location);
Environment.CurrentDirectory = dir;

    // or
    Directory.SetCurrentDirectory(dir);
}

}
`` ''

@imakowski вы можете не контролировать его, но код / ​​приложения не должны полагаться на текущий установленный рабочий каталог. Приложения всегда должны определять свой каталог bin с помощью кода, как я представил выше. В Windows есть несколько вызовов API, которые изменяют текущий рабочий каталог без вашего ведома. Ваше приложение может работать нормально большую часть времени, но затем выйдет из строя после того, как пользователь посетит редко используемую часть вашего приложения.

@rprouse этот код не работает в режиме теневого копирования
var dir = Path.GetDirectoryName(typeof(MySetUpClass).Assembly.Location);

Вы можете использовать это в этом случае:
var dir = Path.GetDirectoryName(new Uri(typeof(MySetUpClass).Assembly.CodeBase).LocalPath);

В качестве альтернативы мы предоставляем его вам как TestContext.CurrentContext.TestDirectory. :-)

Мы используем Uri, как было предложено, с некоторыми корректировками для особых случаев.

В качестве альтернативы мы предоставляем его вам как TestContext.CurrentContext.TestDirectory. :-)

в CurrentContext больше нет свойства TestDirectory. Я использую nunit 3.6.1. есть только WorkDirectory, который в моем случае, когда я начинаю тест с resharper, указывает на неправильное место :(

Есть TestContext.TestDirectory. Это статическое свойство. Я считаю, что WorkDirectory тоже?

ну, я не могу найти его ни с помощью браузера Visual Studio, ни с помощью компилятора, ни с помощью телерического декомпилятора.
но я вижу это в nunit 3.5. не уверен, что не так

Я был неправ.

Это TestContext.CurrentContext.TestDirectory.

Однако в ПОРТАТИВНОЙ сборке его нет.

#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

он есть в 3.6.0, но не в 3.6.1

Я смотрю на текущее репозиторий github, и оно точно такое, как я скопировал и вставил выше.

Вы уверены, что каким-то образом не используете ПОРТАТИВНУЮ сборку?

да я использую это

Ну вот почему его там нет. Он не поддерживается в ПОРТАТИВНОЙ сборке и, насколько мне известно, никогда не поддерживался. Однако я никогда не использовал ПОРТАТИВНУЮ сборку, просто провожу с ней тесты CI.

Спасибо

Directory.SetCurrentDirectory (AppDomain.CurrentDomain.BaseDirectory);

Для людей, которые следят за реальным кодом, собирая воедино то, что @rprouse , это

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

Для глобальной инициализации

Только не заключайте приведенную выше логику в какое-либо пространство имен. т.е.

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

Кроме того, похоже, что TestContext.CurrentContext.TestDirectory имеет больше интеллекта для решения угловых случаев, поэтому я бы выбрал это вместо typeof(MySetUpClass).Assembly.Location

поэтому я бы выбрал это вместо typeof (MySetUpClass) .Assembly.Location

Location возвращает местоположение тени, если сборка копируется в тенях, обычно вам этого не нужно. Вместо этого используйте CodeBase , который возвращает Uri фактического местоположения, из которого он изначально запущен, до любого теневого копирования.

Очевидно, что лучше использовать TestDirectory , но, похоже, есть проблемы с этим свойством, см. # 2872, вызывающие исключения, которые невозможно перехватить. Я не знаю, могут ли они также появиться, если вы используете OneTimeSetup (я полагаю, что нет), но следует проявлять осторожность, пока это не будет решено.