Questions fréquentes (FAQ) sur Live Unit Testing

Live Unit Testing fonctionne avec les trois frameworks de tests unitaires populaires listés dans le tableau suivant. La version minimale prise en charge des adaptateurs et des frameworks est également listée dans le tableau. Les frameworks de tests unitaires sont tous disponibles dans NuGet.org.

Si vous avez des projets de test basés sur MSTest plus anciens qui référencent Microsoft.VisualStudio.QualityTools.UnitTestFramework et que vous ne souhaitez pas passer aux packages NuGet de MSTest plus récents, faites 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 vous sélectionnez la liste déroulante Live Unit Testing) doit indiquer les raisons de ce dysfonctionnement. Live Unit Testing Test peut ne pas fonctionner pour les raisons suivantes :

• Si les packages NuGet référencés par les projets de la solution n’ont pas été restaurés, la fonctionnalité Live Unit Testing ne peut pas fonctionner. Pour résoudre ce problème, exécutez un build explicite de la solution ou restaurez les packages NuGet de la solution avant d’activer Live Unit Testing.

• Si vous utilisez des tests basés sur MSTest dans vos projets, veillez à supprimer la référence à Microsoft.VisualStudio.QualityTools.UnitTestFramework et à ajouter des références aux derniers packages NuGet MSTest, MSTest.TestAdapter (version 1.1.11 au minimum requise) et MSTest.TestFramework (version 1.1.11 au minimum 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 contenir une référence NuGet ou une référence directe au framework de tests xUnit, NUnit ou MSTest. Ce projet doit également faire référence au package NuGet des adaptateurs de test Visual Studio correspondants.

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. Certains problèmes courants sont provoqués par une configuration incorrecte dans l’Assistant d’installation 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 le 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 des 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 qui sont 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 le build. Dans ces cas, l’option « <Personnaliser> » doit être choisie et un ensemble personnalisé des règles qui répertorient uniquement les dossiers d’artefacts doit être répertorié.

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 comme une configuration de solution globale et non pas comme ProjectReferences pour chaque projet, Live Unit Testing peut finir par générer un ensemble incorrect de projets. Pour corriger cela, ajoutez des références explicites entre les projets.

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

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

• Au moins un projet de votre solution doit contenir une référence NuGet ou une référence directe au framework de tests xUnit, NUnit ou MSTest. Ce projet doit également faire référence au package NuGet des adaptateurs de test Visual Studio correspondants. 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 à ce qui est contenu dans l’exemple suivant :

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

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

• Les délais d’expiration constituent un autre problème. É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 de la solution font référence au package de l’adaptateur de test NuGet, chacun d’eux doit être mis à niveau vers la version prise en charge.

• Vérifiez que le fichier .props MSBuild importé à partir du package de l’adaptateur de test est mis à jour correctement. Vérifiez la version/le chemin du package NuGet de l’importation, qui figure généralement vers le 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 de génération de l’instrumentation (Live Unit Testing) qui ne sont pas nécessaires à une génération non instrumentée « standard », vous pouvez ajouter du code à vos fichiers projet ou .target pour vérifier la propriété BuildingForLiveUnitTesting et effectuer les étapes personnalisées avant et après génération. 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 (par exemple, la copie des composants requis) pour une build Live Unit Testing basée sur cette propriété de projet. La personnalisation de votre build avec cette propriété ne modifie pas votre build et affecte uniquement les builds Live Unit Testing.

Par exemple, vous pouvez avoir une cible qui génère des packages NuGet dans le cadre d’une build standard. Vous préférerez sans doute éviter que des packages NuGet soient générés après chaque modification que vous effectuez. Ainsi, vous pouvez 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 des tests depuis la fenêtre de 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 a pour effet de lancer le débogueur à chaque exécution de la méthode (y compris lorsqu’elle est exécutée par Live Unit Testing), après quoi vous pouvez attacher et déboguer le fichier binaire instrumenté. Nous espérons cependant que l’instrumentation est parfaitement transparente pour vous dans la plupart des scénarios utilisateur et que vous n’avez pas besoin de déboguer des binaires instrumentés.

• La fonctionnalité Live Unit Testing ne crée aucun domaine d’application pour exécuter des tests, contrairement aux tests exécutés à partir de la fenêtre Explorateur de tests.

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

• L’Explorateur de tests exécute des tests dans un thread unique cloisonné par défaut, tandis que Live Unit Testing exécute les tests dans plusieurs threads cloisonnés (MTA). Pour exécuter les tests MSTest dans un STA dans Live Unit Testing, complétez la méthode de test ou la classe de conteneur avec l’attribut <STATestMethod> ou <STATestClass> qui se trouve dans le package NuGet MSTest.STAExtensions 1.0.3-beta. Pour NUnit, complétez 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 l’article Utiliser Live Unit Testing dans Visual Studio Enterprise Edition pour connaître les paramètres spécifiques à l’utilisateur. L’inclusion et l’exclusion de tests s’avèrent utiles quand vous souhaitez exécuter un ensemble spécifique de tests pour une session de modification particulière ou pour conserver vos préférences personnelles.

Pour les paramètres spécifiques à la solution, vous pouvez, à l’aide d’un programme, appliquer l’attribut System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute pour empêcher que des méthodes, des propriétés, des classes ou des structures soient 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 de l’instrumentation l’ensemble du projet. Live Unit Testing continue d’exécuter les tests qui n’ont pas été instrumentés, mais leur couverture n’est pas affichée.

Vous pouvez également vérifier si Microsoft.CodeAnalysis.LiveUnitTesting.Runtime est chargé dans le domaine d’application actuel et désactiver les tests selon le résultat. Par exemple, vous pouvez procéder de cette manière 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 être générée même si vous n’apportez 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 si les fichiers cibles de la build n’ont ni les entrées ni les sorties appropriées spécifiées. Les cibles doivent disposer d’une liste d’entrées et de sorties afin que MSBuild puisse effectuer les contrôles à jour appropriés et déterminer si une nouvelle build est requise.

Live Unit Testing démarre une build chaque fois qu’il détecte une modification des fichiers sources. Étant donné que la génération de votre solution génère des fichiers sources, Live Unit Testing bascule dans une boucle de génération infinie. Si toutefois les entrées et sorties de la cible sont vérifiées lorsque Live Unit Testing démarre la deuxième génération (après la détection des fichiers sources qui viennent d’être générés à partir de la génération précédente), il quitte la boucle de génération puisque les vérifications des entrées et des sorties indiquent que tout est à jour.

Les icônes ne sont pas visibles dans l’éditeur si les assemblys sur lesquels agit Live Unit Testing ne sont pas instrumentés pour une raison quelconque. Par exemple, Live Unit Testing n’est pas compatible avec des projets qui définissent <UseHostCompilerIfAvailable>false</UseHostCompilerIfAvailable>. Dans ce cas, votre processus de build doit être mis à jour pour supprimer ce paramètre ou le modifier en true afin de permettre à Live Unit Testing de fonctionner. 

Vous pouvez collecter des journaux plus détaillés de plusieurs manières :

• Accédez à Outils>Options>Live Unit Testing et définissez l’option de journalisation sur Détaillé. La journalisation détaillée fournit 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. Vous pourrez ensuite récupérer à partir de ce fichier les messages détaillés du journal MSBuild compilé à partir des builds Live Unit Testing.

• Affectez à la variable d’environnement utilisateur LiveUnitTesting_TestPlatformLog la valeur 1 pour capturer le journal de la plateforme de test. Vous pourrez ensuite récupérer à partir de [Solution Root]\.vs\[Solution Name]\log\[VisualStudio Process ID] les messages détaillés de la plateforme de test issus des séries de tests Live Unit Testing.

• Créez une variable d’environnement de niveau utilisateur nommée VS_UTE_DIAGNOSTICS et affectez-lui la valeur 1 (ou n’importe quelle valeur), puis redémarrez Visual Studio. L’onglet Sortie - Tests de Visual Studio devrait maintenant contenir un nombre important de consignations.

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 la racine du référentiel et la racine de l’espace de travail.

Oui, mais vous devez vérifier qu’ils sont activés. Si vous utilisez un lecteur de développement, vérifiez que le filtre du système ProjFS(Projected File System) est activé. Par exemple, la commande suivante active ProjFS et Windows Defender :

fsutil devdrv setfiltersallowed PrjFlt, WdFilter

Voir aussi

• Live Unit Testing