Nunit: Directorio de trabajo para pruebas en la consola NUnit 3

Esto es por diseño, como se muestra aquí: https://github.com/nunit/nunit/wiki/Breaking-Changes

En versiones anteriores, NUnit cambió el directorio de trabajo. Ya no lo hace. Puede usar TestContext.TestDirectory para obtener el directorio que contiene el ensamblado de prueba.

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

¡Esto rompe muchas pruebas! ¿Por qué cambiaste eso? Algunas de las pruebas no se pueden corregir porque el código de tiempo de ejecución de la aplicación probada dependía de que el directorio de trabajo es la ubicación del ensamblaje de prueba.

@imakowski, ¿ ha intentado configurar el directorio de trabajo actual en un directorio conocido en una configuración de ensamblaje? Código no probado, pero algo como;

`` C #
[SetUpFixture]
clase pública MySetUpClass
{
[Configuración de una sola vez]
RunBeforeAnyTests ()
{
var dir = Path.GetDirectoryName (typeof (MySetUpClass) .Assembly.Location);
Environment.CurrentDirectory = dir;

    // or
    Directory.SetCurrentDirectory(dir);
}

}
''

@imakowski, es posible que no tenga control sobre él, pero el código / las aplicaciones no deben depender del directorio de trabajo actual que se está configurando. Las aplicaciones siempre deben determinar su directorio bin con un código como el que presenté anteriormente. Hay varias llamadas a API en Windows que cambian el directorio de trabajo actual sin que usted se dé cuenta. Su aplicación podría funcionar bien la mayor parte del tiempo, pero luego fallar después de que un usuario visite una parte de su aplicación que rara vez se usa.

@rprouse este código no funciona cuando está en el modo de instantánea
var dir = Path.GetDirectoryName(typeof(MySetUpClass).Assembly.Location);

Podrías usar esto en ese caso:
var dir = Path.GetDirectoryName(new Uri(typeof(MySetUpClass).Assembly.CodeBase).LocalPath);

Alternativamente, se lo proporcionamos como TestContext.CurrentContext.TestDirectory. :-)

Usamos el Uri como se sugiere con algunos ajustes para casos especiales.

Alternativamente, se lo proporcionamos como TestContext.CurrentContext.TestDirectory. :-)

ya no hay propiedad TestDirectory en CurrentContext. yo uso nunit 3.6.1. solo hay WorkDirectory que, en mi caso, cuando comienzo la prueba desde los puntos de reajuste al lugar equivocado :(

Hay TestContext.TestDirectory. Es una propiedad estática. Creo que WorkDirectory también lo es.

bueno, no puedo encontrarlo usando el navegador de Visual Studio o el compilador o el descompilador telerico.
pero lo veo en nunit 3.5. No estoy seguro de qué está mal

Me equivoqué.

Es TestContext.CurrentContext.TestDirectory.

Sin embargo, no está en la versión PORTÁTIL.

#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

está allí en 3.6.0 pero no en 3.6.1

Estoy mirando el repositorio de github actual, y es exactamente como lo copié y pegué arriba.

¿Estás seguro de que no estás usando la compilación PORTÁTIL de alguna manera?

si, lo estoy usando

Bueno, por eso no está ahí. No es compatible con la compilación PORTÁTIL, y nunca lo ha sido, que yo sepa. Sin embargo, nunca he usado la compilación PORTABLE, simplemente ejecuté las pruebas de CI en su contra.

gracias

Directory.SetCurrentDirectory (AppDomain.CurrentDomain.BaseDirectory);

Para las personas que buscan el código real, juntando lo que dijeron @CharliePoole y @rprouse , es

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

Para inicialización global

Simplemente no encierre la lógica anterior dentro de ningún espacio de nombres. es decir

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

Además, parece que TestContext.CurrentContext.TestDirectory tiene algo más de inteligencia para abordar casos de esquina, por lo que elegiría eso sobre typeof(MySetUpClass).Assembly.Location

así que elegiría eso sobre typeof (MySetUpClass) .Assembly.Location

Location devuelve la ubicación de la sombra si el ensamblaje se copia en la sombra, normalmente no querrá eso. Utilice CodeBase lugar, que devuelve un Uri de la ubicación real desde la que se ejecuta inicialmente, antes de cualquier copia de sombra.

Obviamente, es mejor usar TestDirectory , pero parece haber problemas con esa propiedad, ver # 2872, lo que provoca excepciones que no se pueden detectar. No sé si también pueden aparecer si usa OneTimeSetup (supongo que no), pero se debe tener cuidado hasta que se solucione.