Nunit: Message d'exception de résultat de test approprié lorsque vous appuyez sur `TimeoutAttribute`

Créé le 25 mai 2021  ·  3Commentaires  ·  Source: nunit/nunit

Salut les gars,

Dernièrement, j'étais en train d'expérimenter avec le TimeoutAttribute et j'ai rencontré quelques temps morts pour mes tests. Je n'ai vu qu'un Exception doesn't have a stacktrace comme message de résultat de test, ce qui m'a dérouté à première vue. Puis j'ai réalisé que le test atteignait le délai d'attente.

J'ai essayé de creuser dans le code pour voir si la mise en œuvre d'un message d'exception de délai d'attente est possible, mais je n'ai rien trouvé pour l'instant.

J'aimerais donc suggérer un meilleur message de résultat de test lorsque vous atteignez le délai d'attente.

Code à reproduire :

[Test]
[Timeout(1000)]
public async Task Timeout()
{
    // Arrange

    // Act
    await Task.Delay(2000).ConfigureAwait(false);

    // Assert
    Assert.Pass();
}

Merci et salutations

bug normal

Tous les 3 commentaires

Salut @Prodigio

Comment exécutez-vous les tests (VS, dotnet test ou console runner), quel framework ciblez-vous et quelles versions de NUnit, NUnit3TestAdapter et console runner utilisez-vous ?

Un survol initial du code pourrait indiquer que pour dotnet core, nous ne définissons pas le message, mais uniquement le libellé. Comparer (flux du cadre)
https://github.com/nuni/nunit/blob/b34eba3ac1aa6957157857bddd116256c634afab/src/NUnitFramework/framework/Internal/Commands/TimeoutCommand.cs#L83
contre (dotnet core flow)
https://github.com/nuni/nunit/blob/b34eba3ac1aa6957157857bddd116256c634afab/src/NUnitFramework/framework/Internal/Commands/TimeoutCommand.cs#L110 -L113

Comparez également la différence dans les tests TimeoutCausesOtherwisePassingTestToFailWithoutDebuggerAttached() . Version du framework Dotnet
https://github.com/nuni/nunit/blob/b34eba3ac1aa6957157857bddd116256c634afab/src/NUnitFramework/tests/Attributes/TimeoutTests.cs#L297 -L299
version de base de dotnet
https://github.com/nuni/nunit/blob/b34eba3ac1aa6957157857bddd116256c634afab/src/NUnitFramework/tests/Attributes/TimeoutTests.cs#L367 -L369

Je ne sais pas si cette différence est intentionnelle, mais cela ressemble à une erreur. Comme nous n'écrivons rien dans le message pour dotnet core, le XML résultant ne contient aucune information et ne peut donc pas être présenté à l'utilisateur. Sur le framework dotnet, le test aura le message d'erreur suivant Test exceeded Timeout value of 1000ms

Salut @mikkelbu ,

désolé pour les informations manquantes. C'est ici:

  • Localement, j'exécute nos tests avec Resharper dans VS 2019
  • Notre serveur CI est TeamCity, où nous exécutons les tests « nus » d'une part avec dotnet test et d'autre part avec l'aide de NUKE et dotnet test , pour certains rapports de couverture
  • Cibler .NET Core 3.1 dans tous les projets de test

Je vois le même message Exception doesn't have a stacktrace localement et sur TeamCity.

Je n'utilise pas la console. Les autres versions de NUnit sont :

  • NUnit v3.13.2
  • NUnit.Engine v3.12.0
  • NUnit3TestAdapter v4.0.0-beta.2

J'ai remarqué qu'en plus de NUnit, nous avons également Microsoft.NET.Test.Sdk v.16.9.4 installé en tant que package NuGet. Cela pourrait-il être un problème?

Merci!

Salut @Prodigio

Merci pour toutes les informations. Je suis sûr que les informations manquantes sont dues au fait que vous ciblez .NET Core 3.1 et que nous avons fait une erreur dans nunit/nunit#3190.

Cela étant dit, je ne pense pas que nous enregistrions la trace de pile lorsque le test échoue en raison d'un délai d'attente, car nous ne savons pas jusqu'où nous sommes dans le code (donc où exactement la trace de pile doit-elle pointer). Les deux appels à context.CurrentResult.SetResult ci-dessus ont un troisième argument qui est le stacktrace, mais nous ne le remplissons pas.

Mais je pense que nous devrions corriger le flux .NET Core, donc nous rapportons également Test exceeded Timeout value ... tant que message.

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