169 votes

Comment sauter des tests spécifiques dans xUnit en fonction de la plate-forme actuelle ?

  • J'ai un assemblage que j'ai construit sous Windows
  • Je veux exécuter les tests xUnit sur mono sous Linux.

Cependant, j'ai constaté que si 400 de ces tests peuvent s'exécuter (dans l'ordre), certains tests bloquent l'exécution de xUnit ou l'arrêtent complètement.

Je n'ai pas soins si certains tests ne peuvent pas être exécutés sous Linux, c'est que certains tests sont liés au DTC et à certains gommes non gérées que nous n'avons pas besoin de prendre en charge.

Ce que je veux cependant, c'est appliquer un ignore à ces tests, et que le fait que le test ait été ignoré soit signalé correctement dans la sortie de la compilation.

La question peut se résumer à un certain nombre de solutions possibles.

  • Comment exécuter des tests spécifiques dans xUnit via le lanceur de console (je n'ai pas trouvé de documentation à ce sujet, peut-être que je ne cherche pas assez) ?
  • Est-il possible d'aller dans l'autre sens et de dire "Voici un assemblage, veuillez ignorer ces tests spécifiques" ?
  • Il a été suggéré que l'attribution d'un attribut à ces tests serait un meilleur moyen de documenter formellement le fait que ces tests sont spécifiques à une plate-forme.

Si je pouvais éviter de trop modifier le code original, ce serait formidable, car le code n'est pas vraiment à moi, et l'application de nombreux hacks multi-plateformes ne serait probablement pas très bien perçue.

314voto

richardwhatever Points 1270

XUnit v2.0 est maintenant disponible. Les tests skippables sont directement supportés par cette version. Utiliser :

[Fact (Skip = "specific reason")]

73voto

Dominik Lemberger Points 1076

Il existe désormais de nouvelles options.

Ajouter un paquet Nuget Fait à sauter qui vous permet d'utiliser [SkippableFact] au lieu de [Fact] et vous pouvez utiliser Skip.<xyz> à l'intérieur d'un test pour sauter dynamiquement le test en cours d'exécution.

Exemple :

[SkippableFact]
public void SomeTestForWindowsOnly()
{
    Skip.IfNot(Environment.IsWindows);

    // Test Windows only functionality.
}

70voto

Igor Zevaka Points 32586

J'éviterais d'externaliser les tests de saut (c'est-à-dire un fichier de configuration/commande si c'est possible). Cela va à l'encontre de la facilité d'exécution des tests et de leur fiabilité. Faire en sorte que les tests soient ignorés dans le code est l'approche la plus sûre lorsque d'autres personnes commencent à s'impliquer.

Je vois un certain nombre d'options, en voici deux qui impliquent une modification du code existant.

Option 1 - La plus intrusive, la détection de la plate-forme au moment de la compilation

Dans la solution VS, définissez une autre configuration qui définit un drapeau de précompilation. MONOWIN (pour qu'il y ait explicitement un drapeau indiquant qu'il s'agit de code compilé sous Windows et destiné à être utilisé sous Mono).

Définissez ensuite un attribut qui fera en sorte que le test soit ignoré lorsqu'il sera compilé pour Mono :

public class IgnoreOnMonoFactAttribute : FactAttribute {
#if MONOWIN
    public IgnoreOnMonoFactAttribute() {
        Skip = "Ignored on Mono";
    }
#endif
}

Il est en fait difficile de trouver des avantages à cette méthode, car elle implique une simulation avec la solution originale et ajoute une autre confirmation qui doit être prise en charge.

Option 2 - quelque peu intrusive - détection de la plate-forme d'exécution

Voici une solution similaire à l'option 1, sauf qu'aucune configuration distincte n'est nécessaire :

public class IgnoreOnMonoFactAttribute : FactAttribute {

    public IgnoreOnMonoFactAttribute() {
        if(IsRunningOnMono()) {
            Skip = "Ignored on Mono";
        }
    }
    /// <summary>
    /// Determine if runtime is Mono.
    /// Taken from http://stackoverflow.com/questions/721161
    /// </summary>
    /// <returns>True if being executed in Mono, false otherwise.</returns>
    public static bool IsRunningOnMono() {
        return Type.GetType("Mono.Runtime") != null;
    }
}

Note 1

Le programme d'exécution xUnit exécutera une méthode deux fois si elle est marquée par l'option [Fact] y [IgnoreOnMonoFact] . (CodeRush ne le fait pas, dans ce cas je suppose que xUnit est correct). Cela signifie que toutes les méthodes de test doivent avoir [Fact] remplacé par [IgnoreOnMonoFact]

Note 2

Le programme de test CodeRush a toujours exécuté le [IgnoreOnMonoFact] mais il n'a pas tenu compte de la [Fact(Skip="reason")] test. Je suppose que cela est dû au fait que CodeRush reflète xUnit et ne l'exécute pas à l'aide des bibliothèques xUnit. Cela fonctionne parfaitement avec xUnit runner.

13voto

n8ross Points 11

[Fact(Skip="reason")]

fonctionne, mais je préfère utiliser les traits

[Fact, Trait("type","unit")]
public void MyUnitTest(){
  // given 
  // when
  // then
}

[Fact, Trait("type","http")]
public void MyHttpIntegrationTest(){
  // given 
  // when do things over HTTP
  // then
}

utilisation

dotnet test --filter type=unit

cela protège nos builds contre l'exécution accidentelle de tests d'intégration que les développeurs ont oublié d'ignorer, par exemple. [Fact(Skip="Integration")] Cependant, il exige que les tests unitaires "s'engagent" dans l'IC en ajoutant les traits corrects, ce qui, il faut le reconnaître, n'est pas une bonne chose.

3voto

RAM Points 892

La solution de Dominik fonctionne pour moi avec ce code :

[SkippableFact]
public void Get_WhenCall_ReturnsString()
{
    // Arrange
    Skip.IfNot(RuntimeInformation.IsOSPlatform(OSPlatform.Windows));

    // Act

    // Assert

}

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X