Forum aux questions sur Live Unit Testing

Live Unit Testing fonctionne avec les trois frameworks de test unitaire populaires répertoriés dans le tableau suivant. La version minimale prise en charge de leurs adaptateurs et infrastructures est également répertoriée dans le tableau. Les frameworks de test unitaire sont tous disponibles à partir de NuGet.org.

Si vous avez des projets de test MSTest plus anciens qui référencent Microsoft.VisualStudio.QualityTools.UnitTestFramework et que vous ne souhaitez pas passer aux packages NuGet MSTest plus récents, effectuez une mise à niveau vers Visual Studio 2019 ou Visual Studio 2017.

Oui. Live Unit Testing fonctionne avec .NET Core et .NET Framework.

La fenêtre Sortie (lorsque la liste déroulante Live Unit Testing est sélectionnée) doit vous indiquer pourquoi Live Unit Testing ne fonctionne pas. Live Unit Testing peut ne pas fonctionner pour l’une des raisons suivantes :

• Si les packages NuGet référencés par les projets de la solution n’ont pas été restaurés, Live Unit Testing ne fonctionne pas. L’exécution d’une build explicite de la solution ou la restauration de packages NuGet dans la solution avant d’activer Live Unit Testing doit résoudre ce problème.

• Si vous utilisez des tests MSTest dans vos projets, veillez à supprimer la référence à Microsoft.VisualStudio.QualityTools.UnitTestFrameworket à ajouter des références aux derniers packages NuGet MSTest, MSTest.TestAdapter (une version minimale de 1.1.11 est requise) et MSTest.TestFramework (une version minimale de 1.1.11 est requise). Pour plus d’informations, consultez la section « Frameworks de test pris en charge » de l’article Utiliser Live Unit Testing dans Visual Studio.

• Au moins un projet de votre solution doit avoir une référence NuGet ou une référence directe à l’infrastructure de test xUnit, NUnit ou MSTest. Ce projet doit également référencer un package NuGet des adaptateurs de test Visual Studio correspondant.

Les erreurs de génération sont signalées dans la fenêtre Sortie lorsque la liste déroulante Live Unit Testing est sélectionnée. Il existe quelques problèmes courants provoqués par une configuration incorrecte dans l’Assistant installation de qui peuvent entraîner des problèmes de génération dans Live Unit Testing.

• Si la propriété racine de l’espace de travail est trop longue, il est possible que la build échoue en raison d’exceptions indiquant que le chemin d’accès est trop long.

• Si la propriété racine du référentiel ne pointe pas vers la racine du référentiel, l’espace de travail est rempli avec le mauvais jeu de fichiers.

• Pour les référentiels Git, la propriété Exclure les fichiers évite généralement de copier les fichiers spécifiés dans le fichier gitignore. Toutefois, il est possible d’archiver des fichiers dans le référentiel Git ignorés ou d’exécuter des outils qui génèrent automatiquement des fichiers, mais ils ne sont pas générés pendant la génération. Dans ces cas, l’option «<>personnalisée » doit être choisie et un ensemble personnalisé de règles qui répertorient uniquement les dossiers d’artefacts doivent être répertoriés.

Outre les problèmes décrits précédemment, les configurations de projet suivantes qui peuvent ne pas être générées correctement.

• Si les dépendances de projet sont spécifiées en tant que configuration de solution globale et non comme ProjectReferences pour chaque projet, Live Unit Testing peut finir par générer l’ensemble incorrect de projets. Pour résoudre ce problème, ajoutez des références explicites entre des projets.

• Jusqu’à ce qu’une playlist Live Unit Testing soit choisie, Live Unit Testing ne génère pas de projets. Pour résoudre ce problème, incluez certains tests dans la playlist Live Unit Testing.

• Si vous utilisez des tests MSTest dans vos projets, veillez à supprimer la référence à Microsoft.VisualStudio.QualityTools.UnitTestFrameworket à ajouter des références aux derniers packages NuGet MSTest, MSTest.TestAdapter (une version minimale de 1.1.11 est requise) et MSTest.TestFramework (une version minimale de 1.1.11 est requise). Pour plus d’informations, consultez frameworks de test pris en charge.

• Au moins un projet de votre solution doit avoir une référence NuGet ou une référence directe à l’infrastructure de test xUnit, NUnit ou MSTest. Ce projet doit également référencer un package NuGet des adaptateurs de test Visual Studio correspondant. L’adaptateur de test Visual Studio peut également être référencé via un fichier .runsettings. Le fichier .runsettings doit avoir une entrée semblable à l’exemple suivant :

<RunSettings>
    <RunConfiguration>
          <TestAdaptersPaths>path-to-your-test-adapter</TestAdaptersPaths>
    </RunConfiguration>
</RunSettings>

Live Unit Testing ne peut pas générer les projets de générateur source avec instrumentation. En raison de la façon dont le compilateur C# configure le chargement d’assembly pour les générateurs sources, la tentative de génération de projets de générateur source avec instrumentation ne parvient pas à charger des assemblys Live Unit Testing.

Vous pouvez définir <ExcludeFromCodeCoverage>true</ExcludeFromCodeCoverage> propriété dans les fichiers csproj du générateur source pour créer ces projets dans Live Unit Testing.

Live Unit Testing exécute la build à l’intérieur de son propre processus pour des raisons de performances. Si ce processus de génération distinct provoque une erreur, vous pouvez définir <UseInProcMSBuildNode>false</UseInProcMSBuildNode> sur le fichier .lutconfig pour vous assurer que toutes les builds se produisent dans le processus MSBuild.

• Un problème courant est que tous les fichiers ne sont pas copiés dans le dossier de test. Vous devrez peut-être ajouter des éléments dépendance de test Live Unit Testing aux fichiers csproj.

• Un autre problème est les délais d’expiration. Étant donné que Live Unit Testing exécute des tests indéfiniment, il abandonne automatiquement une exécution si les tests s’exécutent trop longtemps. Vous pouvez augmenter le délai d’expiration dans l’Assistant du projet.

• Si plusieurs projets dans la solution référencent le package d’adaptateur de test NuGet, chacun d’eux doit être mis à niveau vers la version prise en charge.

• Vérifiez que msBuild fichier .props importé à partir du package de l’adaptateur de test est également mis à jour correctement. Vérifiez la version/le chemin d’accès du package NuGet de l’importation, qui se trouve généralement en haut du fichier projet, comme suit :

    <Import Project="..\packages\xunit.runner.visualstudio.2.2.0\build\net20\xunit.runner.visualstudio.props" Condition="Exists('..\packages\xunit.runner.visualstudio.2.2.0\build\net20\xunit.runner.visualstudio.props')" />
  

Si votre solution nécessite des étapes personnalisées pour générer pour l’instrumentation (Live Unit Testing) qui ne sont pas requises pour la build non instrumentée « standard », vous pouvez ajouter du code à votre projet ou .targets fichiers qui vérifient la propriété BuildingForLiveUnitTesting et effectuent des étapes de pré/post-génération personnalisées. Vous pouvez également choisir de supprimer certaines étapes de génération (telles que la publication ou la génération de packages) ou d’ajouter des étapes de génération (comme la copie des prérequis) à une build Live Unit Testing basée sur cette propriété de projet. La personnalisation de votre build basée sur cette propriété ne modifie pas votre build normale de quelque manière que ce soit et affecte uniquement les builds Live Unit Testing.

Par exemple, il peut y avoir une cible qui produit des packages NuGet pendant une build normale. Vous ne souhaitez probablement pas que les packages NuGet soient générés après chaque modification que vous apportez. Vous pouvez donc désactiver cette cible dans la build Live Unit Testing en procédant comme suit :

<Target Name="GenerateNuGetPackages" BeforeTargets="AfterBuild" Condition="'$(BuildingForLiveUnitTesting)' != 'true'">
    <Exec Command='"$(MSBuildThisFileDirectory)..\tools\GenPac" '/>
</Target>

Il existe plusieurs différences :

• L’exécution ou le débogage de tests à partir de la fenêtre l’Explorateur de tests exécute des fichiers binaires réguliers, tandis que Live Unit Testing exécute des fichiers binaires instrumentés. Si vous souhaitez déboguer des fichiers binaires instrumentés, l’ajout d’un appel de méthode Debugger.Launch dans votre méthode de test entraîne le lancement du débogueur chaque fois que cette méthode est exécutée (y compris lorsqu’elle est exécutée par Live Unit Testing), et vous pouvez ensuite attacher et déboguer le binaire instrumenté. Toutefois, nous espérons que l’instrumentation est transparente pour vous pour la plupart des scénarios utilisateur et que vous n’avez pas besoin de déboguer des fichiers binaires instrumentés.

• Live Unit Testing ne crée pas de domaine d’application pour exécuter des tests, mais les tests s’exécutent à partir de la fenêtre de l’Explorateur de tests créent un domaine d’application.

• Live Unit Testing exécute des tests dans chaque assembly de test séquentiellement. Dans Explorateur de tests, vous pouvez choisir d’exécuter plusieurs tests en parallèle.

• Explorateur de tests exécute des tests dans un appartement à thread unique (STA) par défaut, tandis que Live Unit Testing exécute des tests dans un appartement multithread (MTA). Pour exécuter des tests MSTest dans STA dans Live Unit Testing, décorez la méthode de test ou la classe conteneur avec l’attribut <STATestMethod> ou <STATestClass> qui se trouve dans le package NuGet MSTest.STAExtensions 1.0.3-beta. Pour NUnit, décorez la méthode de test avec l’attribut <RequiresThread(ApartmentState.STA)> et pour xUnit, avec l’attribut <STAFact>.

Consultez la section « Inclure et exclure des projets de test et des méthodes de test » de la Utiliser Live Unit Testing dans Visual Studio article pour le paramètre spécifique à l’utilisateur. L’inclusion ou l’exclusion des tests est utile lorsque vous souhaitez exécuter un ensemble spécifique de tests pour une session d’édition particulière ou pour conserver vos propres préférences personnelles.

Pour les paramètres spécifiques à la solution, vous pouvez appliquer l’attribut System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute par programmation pour exclure les méthodes, propriétés, classes ou structures d’être instrumentées par Live Unit Testing. En outre, vous pouvez également définir la propriété <ExcludeFromCodeCoverage> sur true dans votre fichier projet pour exclure tout le projet d’être instrumenté. Live Unit Testing exécute toujours les tests qui n’ont pas été instrumentés, mais leur couverture ne sera pas visualisée.

Vous pouvez également vérifier si Microsoft.CodeAnalysis.LiveUnitTesting.Runtime est chargé dans le domaine d’application actuel et désactiver les tests en fonction de la raison pour laquelle. Par exemple, vous pouvez effectuer quelque chose comme suit avec xUnit :

[ExcludeFromCodeCoverage]
public class SkipLiveFactAttribute : FactAttribute
{
   private static bool s_lutRuntimeLoaded = AppDomain.CurrentDomain.GetAssemblies().Any(a => a.GetName().Name ==
                                            "Microsoft.CodeAnalysis.LiveUnitTesting.Runtime");
   public override string Skip => s_lutRuntimeLoaded ? "Test excluded from Live Unit Testing" : "";
}

public class Class1
{
   [SkipLiveFact]
   public void F()
   {
      Assert.True(true);
   }
}

Votre solution peut générer même si vous n’effectuez pas de modifications si le processus de génération génère du code source qui fait partie de la solution elle-même et que vos fichiers cibles de build n’ont pas d’entrées et de sorties appropriées spécifiées. Les cibles doivent recevoir une liste d’entrées et de sorties afin que MSBuild puisse effectuer les vérifications de up-to-date appropriées et déterminer si une nouvelle build est requise.

Live Unit Testing démarre une build chaque fois qu’elle détecte que les fichiers sources ont changé. Étant donné que la build de votre solution génère des fichiers sources, Live Unit Testing entre dans une boucle de build infinie. Si, toutefois, les entrées et sorties de la cible sont vérifiées lorsque Live Unit Testing démarre la deuxième build (après avoir détecté les fichiers sources nouvellement générés à partir de la build précédente), il sort de la boucle de build, car les entrées et sorties vérifient que tout est up-to-date.

Vous ne voyez peut-être pas d’icônes dans l’éditeur si les assemblys sur lesquels Live Unit Testing fonctionne ne sont pas instrumentés pour une raison quelconque. Par exemple, Live Unit Testing n’est pas compatible avec les projets qui définissent <UseHostCompilerIfAvailable>false</UseHostCompilerIfAvailable>. Dans ce cas, votre processus de génération doit être mis à jour pour supprimer ce paramètre ou le remplacer par true pour que Live Unit Testing fonctionne. 

Vous pouvez effectuer plusieurs opérations pour collecter des journaux plus détaillés :

• Accédez à Tools>Options>Live Unit Testing et modifiez l’option de journalisation en détaillée. La journalisation détaillée entraîne l’affichage des journaux plus détaillés dans la fenêtre sortie.

• Définissez la variable d’environnement utilisateur LiveUnitTesting_BuildLog sur le nom du fichier que vous souhaitez utiliser pour capturer le journal MSBuild. Les messages détaillés du journal MSBuild des builds Live Unit Testing peuvent ensuite être récupérés à partir de ce fichier.

• Définissez la variable d’environnement utilisateur LiveUnitTesting_TestPlatformLog sur 1 pour capturer le journal de la plateforme de test. Les messages détaillés du journal de plateforme de test des exécutions Live Unit Testing peuvent ensuite être récupérés à partir de [Solution Root]\.vs\[Solution Name]\log\[VisualStudio Process ID].

• Créez une variable d’environnement au niveau de l’utilisateur nommée VS_UTE_DIAGNOSTICS et définissez-la sur 1 (ou n’importe quelle valeur) et redémarrez Visual Studio. Vous devez maintenant voir beaucoup de journalisation dans la sortie - Tests onglet dans Visual Studio.

Non, vous ne devez pas ouvrir ou modifier les fichiers sous les répertoires de génération et de test du dossier de l’espace de travail. Live Unit Testing doit gérer tous les fichiers du dossier src pour les synchroniser entre le racine du référentiel et racine de l’espace de travail.

Oui, mais vous devez vous assurer qu’elle est activée. Si vous utilisez un lecteur de développement, vérifiez que le filtre de système de fichiers projeté (ProjFS) est activé. Par exemple, la commande suivante active ProjFS et Windows Defender :

fsutil devdrv setfiltersallowed PrjFlt,WdFilter

Voir aussi

• live Unit Testing