Nunit: Répertoire de travail pour les tests dans la console NUnit 3

Créé le 26 nov. 2015  ·  21Commentaires  ·  Source: nunit/nunit

Dans NUnit 2.6.4, le répertoire de travail pour mes tests était défini sur le répertoire bin/Debug de la DLL de test. Cela m'a permis de charger des fichiers externes dans les tests par chemin relatif.

Il semble que le répertoire de travail soit désormais défini sur le répertoire de travail du programme d'exécution de la console. Est-ce par conception?

Comment puis-je laisser les résultats des tests (fichiers *.xml) dans le répertoire de travail du programme d'exécution de la console tout en ayant le répertoire de travail pour mes tests défini sur bin/Debug ?

notabug

Commentaire le plus utile

@imakowski avez-vous essayé de définir le répertoire de travail actuel sur un répertoire connu dans une configuration d'assemblage ? Code non testé, mais quelque chose comme ;

``` C#
[SetUpFixture]
classe publique MySetUpClass
{
[OneTimeSetUp]
Exécuter avant tous les tests()
{
var dir = Path.GetDirectoryName(typeof(MySetUpClass).Assembly.Location);
Environment.CurrentDirectory = dir;

    // or
    Directory.SetCurrentDirectory(dir);
}

}
```

Tous les 21 commentaires

C'est par conception, comme indiqué ici : https://github.com/nunit/nunit/wiki/Breaking-Changes

Dans les versions précédentes, NUnit modifiait le répertoire de travail. Il ne le fait plus. Vous pouvez utiliser TestContext.TestDirectory pour obtenir le répertoire qui contient l'assembly de test.

Cela casse beaucoup de test! Pourquoi tu as changé ça ? Certains des tests ne peuvent pas être corrigés car le code d'exécution de l'application testée avait une dépendance selon laquelle le répertoire de travail est l'emplacement de l'assembly de test.

@imakowski avez-vous essayé de définir le répertoire de travail actuel sur un répertoire connu dans une configuration d'assemblage ? Code non testé, mais quelque chose comme ;

``` C#
[SetUpFixture]
classe publique MySetUpClass
{
[OneTimeSetUp]
Exécuter avant tous les tests()
{
var dir = Path.GetDirectoryName(typeof(MySetUpClass).Assembly.Location);
Environment.CurrentDirectory = dir;

    // or
    Directory.SetCurrentDirectory(dir);
}

}
```

@imakowski, vous

@rprouse ce code ne fonctionne pas lorsqu'il est en mode
var dir = Path.GetDirectoryName(typeof(MySetUpClass).Assembly.Location);

Vous pouvez utiliser ceci dans ce cas :
var dir = Path.GetDirectoryName(new Uri(typeof(MySetUpClass).Assembly.CodeBase).LocalPath);

Alternativement, nous vous le fournissons en tant que TestContext.CurrentContext.TestDirectory. :-)

Nous utilisons l'Uri comme suggéré avec quelques ajustements pour des cas particuliers.

Alternativement, nous vous le fournissons en tant que TestContext.CurrentContext.TestDirectory. :-)

il n'y a plus de propriété TestDirectory dans CurrentContext. j'utilise nunit 3.6.1. il n'y a que WorkDirectory qui, dans mon cas, lorsque je démarre le test à partir du réaffûteur, pointe au mauvais endroit :(

Il y a TestContext.TestDirectory. C'est une propriété statique. Je crois que WorkDirectory l'est aussi ?

eh bien, je ne peux pas le trouver en utilisant le navigateur ou le compilateur Visual Studio ou le décompilateur teleric.
mais je le vois dans nunit 3.5. Je ne sais pas ce qui ne va pas

J'avais tort.

C'est TestContext.CurrentContext.TestDirectory.

Cependant, il n'est pas là sur la version PORTABLE.

#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

il est là dans 3.6.0 mais pas dans 3.6.1

Je regarde le référentiel github actuel, et c'est exactement comme j'ai copié et collé ci-dessus.

Êtes-vous sûr de ne pas utiliser la version PORTABLE d'une manière ou d'une autre ?

oui je l'utilise

Eh bien, c'est pourquoi il n'est pas là. Il n'est pas pris en charge dans la version PORTABLE, et ne l'a jamais été, à ma connaissance. Cependant, je n'ai jamais utilisé la version PORTABLE, il suffit d'exécuter les tests CI par rapport à celle-ci.

Merci

Directory.SetCurrentDirectory(AppDomain.CurrentDomain.BaseDirectory);

Pour les personnes qui recherchent le code réel, en rassemblant ce que @CharliePoole et @rprouse ont dit, c'est

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

Pour l'initialisation globale

Ne placez simplement pas la logique ci-dessus dans un espace de noms. c'est à dire

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

De plus, il semble que le TestContext.CurrentContext.TestDirectory ait plus d'intelligence pour traiter les cas difficiles, donc je choisirais cela plutôt que typeof(MySetUpClass).Assembly.Location

donc je choisirais ça plutôt que typeof(MySetUpClass).Assembly.Location

Location renvoie l'emplacement de l'ombre si l'assemblage est copié par ombre, ce que vous ne voudriez généralement pas. Utilisez plutôt CodeBase , qui renvoie un Uri de l'emplacement réel à partir duquel il est initialement exécuté, avant tout cliché instantané.

Évidemment, il est préférable d'utiliser TestDirectory , mais il semble y avoir des problèmes avec cette propriété, voir #2872, provoquant des exceptions qui ne peuvent pas être interceptées. Je ne sais pas s'ils peuvent également apparaître si vous utilisez OneTimeSetup (je suppose que non), mais il faut faire attention jusqu'à ce que cela soit résolu.

Cette page vous a été utile?
0 / 5 - 0 notes