Configurer et utiliser Live Unit Testing

Lors du développement d’une application, Live Unit Testing exécute automatiquement en arrière-plan tous les tests unitaires affectés, et présente en temps réel les résultats et la couverture du code. Lorsque vous modifiez votre code, Live Unit Testing fournit des commentaires sur l’impact de vos modifications sur les tests existants et vous indique si le code que vous avez ajouté est couvert par un ou plusieurs tests existants. Ce commentaire vous rappelle d’écrire des tests unitaires lorsque vous apportez des correctifs de bogues ou ajoutez de nouvelles fonctionnalités.

Lorsque vous utilisez Live Unit Testing pour vos tests, il conserve des données sur l’état de vos tests. L’utilisation de données persistantes permet à Live Unit Testing d’offrir des performances supérieures lors de l’exécution de vos tests de façon dynamique en réponse à des modifications du code.

Live Unit Testing est disponible uniquement dans Visual Studio Enterprise pour des projets ciblant .NET Core ou .NET Framework.

Frameworks de test pris en charge

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 affichée. 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, effectuez une mise à niveau vers Visual Studio 2019 ou Visual Studio 2017.

Dans certains cas, vous devrez peut-être restaurer explicitement les packages NuGet référencés par un projet afin que Live Unit Testing fonctionne. Vous avez deux options :

• Restaurez en effectuant une build explicite de la solution. Sélectionnez Générer>Régénérer la solution dans le menu Visual Studio du plus haut niveau.
• Restaurez des packages dans la solution. Cliquez avec le bouton droit sur la solution, puis sélectionnez Restaurer des packages NuGet.

Configurer

La première fois que vous démarrez Live Unit Testing pour une solution, un assistant de configuration vous permet de configurer la façon dont Live Unit Testing doit générer et exécuter des tests.

Lorsque Live Unit Testing est arrêté, vous pouvez également ouvrir l’assistant de configuration en accédant à Tester>Live Unit Testing>Configurer Live Unit Testing pour la solution.

Lorsque Live Unit Testing s’exécute, il crée un espace de travail, qui est une copie du référentiel d’origine. Live Unit Testing applique ensuite toutes les modifications non enregistrées que vous avez apportées dans Visual Studio à l’espace de travail, effectue une build, effectue une exécution de test et signale la couverture du code la plus récente.

La première chose à configurer à l’aide de l’assistant est l’emplacement où se trouvent les fichiers à copier et où ils doivent être copiés.

Racine du référentiel

La racine du référentiel spécifie le dossier qui sera copié pour créer l’espace de travail Live Unit Testing. Il doit s’agir du dossier racine du référentiel. Autrement dit, il doit contenir l’ensemble des sources, fichiers binaires et outils. Dans les cas où le fichier de solution n’est pas présent sous la racine du référentiel, il est possible que la racine du référentiel doive être modifiée.

Racine de l’espace de travail

La racine de l’espace de travail spécifie le dossier dans lequel Live Unit Testing conserve un clone du référentiel. Observez les exceptions indiquant que le chemin d’accès est trop long. Par défaut, la racine est créée sous votre dossier d’accueil. Toutefois, par exemple, si vous devez normalement créer votre référentiel sous le lecteur C, la racine de l’espace de travail peut être définie par exemple sur C:\lut\Repo.

Spécifier les fichiers exclus

Tous les fichiers ne doivent pas être copiés dans l’espace de travail Live Unit Testing. Tous les artefacts générés pendant la génération doivent être exclus de la copie afin que les builds standard n’interfèrent pas avec les builds Live Unit Testing. En outre, la commande nuget restore standard ne doit pas interférer avec la commande Live Unit Testing nuget restore.

Par défaut, Live Unit Testing exclut l’un des deux modèles de fichiers :

• Pour les référentiels Git, les fichiers spécifiés dans le fichier gitignore ne sont pas copiés dans l’espace de travail Live Unit Testing.
• Pour les référentiels non Git, une liste de dossiers de base, tels que bin/ et obj/, n’est pas copiée dans l’espace de travail Live Unit Testing.

Pour les référentiels plus complexes, vous devrez peut-être spécifier votre propre fichier ignore. Sélectionnez l’option « <Personnalisé> » dans l’assistant. Après avoir sélectionné Suivant, le contenu d’un fichier ignore personnalisé créé par Live Unit Testing s’affiche une fois l’assistant terminé. C’est le fichier lutignore.

Structure de fichiers lutignore

Le fichier lutignore utilise le même format qu’un fichier gitignore. Il doit contenir des règles qui correspondent aux dossiers ou fichiers générés pendant la génération afin qu’ils ne soient pas copiés dans l’espace de travail. Pour la plupart des modèles de projet par défaut, le fichier ignore suivant est suffisant :

[BB]IN
[OO]BJ
# WILL NOT COPY ANY BIN AND OBJ FOLDERS TO THE LIVE UNIT TESTING WORKSPACE

Si votre référentiel possède un dossier de build unique, le fichier ignore doit répertorier ce dossier à la place :

[AA]RTIFACTS/
# WILL NOT COPY THE ARTIFACTS FOLDER TO THE LIVE UNIT TESTING WORKSPACE

Si votre référentiel inclut d’autres outils dans le dossier de build, ces outils doivent être exclus dans l’ensemble de modèles correspondants :

[AA]RTIFACTS/
![AA]RTIFACTS/TOOLS/
# WILL NOT COPY THE ARTIFACTS FOLDER TO THE LIVE UNIT TESTING WORKSPACE
# HOWEVER IT WILL COPY THE TOOLS SUBFOLDER THAT MIGHT CONTAIN TOOLS AND UTILITIES

Options de génération

La deuxième partie de la page de configuration de l’assistant est l’emplacement où vous configurez les options de génération :

• Générer des fichiers PDB : pour accélérer la génération, Live Unit Testing ne génère pas de fichiers PDB pendant les builds. Ces fichiers de symboles vous permettent d’accéder aux traces de pile lorsque des échecs de test se produisent.
• Générer à l’aide de plusieurs cœurs d’UC : par défaut, Live Unit Testing effectue des builds à l’aide de plusieurs cœurs d’UC, ce qui améliore les temps de génération. Si votre machine ralentit ou si la génération de votre solution à l’aide de plusieurs processeurs échoue, ne sélectionnez pas cette option.

Options d’exécution de test

La dernière partie de la page de configuration de l’assistant est l’emplacement où vous avez configuré les options d’exécution de test :

• Délai d’expiration du cas de test : certains tests peuvent prendre beaucoup de temps. La définition de ce champ abandonne automatiquement les exécutions si l’un des tests dépasse une durée spécifique. Les tests peuvent être automatiquement annulés.
• Utiliser plusieurs processeurs : par défaut, Live Unit Testing tente d’utiliser plusieurs processeurs pour accélérer les performances d’exécution. Si votre machine ralentit ou si votre solution ne peut pas exécuter de tests en parallèle, ne sélectionnez pas cette option. Par exemple, ces scénarios peuvent se produire si plusieurs tests essaient d’écrire/de lire à partir des mêmes chemins de fichier.

Plus de configuration

Configurez Live Unit Testing en sélectionnant Outils>Options dans la barre de menus Visual Studio de niveau supérieur. Dans le volet gauche de la boîte de dialogue Options, sélectionnez Live Unit Testing.

Une fois Live Unit Testing activé (consultez Démarrer, suspendre et arrêter Live Unit Testing), vous pouvez également ouvrir la boîte de dialogue Options en sélectionnant Tester>Live Unit Testing>Options.

L’image suivante montre les options de configuration de Live Unit Testing disponibles dans la boîte de dialogue.

Les options configurables sont les suivantes :

• Interruption de Live Unit Testing quand une solution est générée et déboguée.

• L’interruption de Live Unit Testing lorsque la batterie d’un système passe en dessous d’un seuil défini.

• Possibilité de supprimer toutes les données persistantes. Cette fonctionnalité est utile lorsque Live Unit Testing se comporte de manière imprévisible ou inattendue, ce qui suggère que les données persistantes sont endommagées.

• La quantité maximale de mémoire que les processus Live Unit Testing peuvent consommer.

• Le niveau des informations écrites dans la fenêtre Sortie de Live Unit Testing.

  Les options incluent : aucune journalisation (Aucune), messages d’erreur uniquement (Erreur), erreur et messages d’information (Info, la valeur par défaut) ou tous les détails (Commentaires).

  Vous pouvez également afficher une sortie détaillée dans la fenêtre Sortie de Live Unit Testing en affectant une valeur de 1 à une variable d’environnement au niveau de l’utilisateur nommée VS_UTE_DIAGNOSTICS. Redémarrez ensuite Visual Studio.

  Pour capturer dans un fichier les messages détaillés du journal MSBuild à partir de Live Unit Testing, définissez la variable d’environnement utilisateur LiveUnitTesting_BuildLog en fonction du nom du fichier qui doit contenir le journal.

Personnaliser votre build pour Live Unit Testing

Pour les solutions plus complexes, il peut être nécessaire de personnaliser davantage la build. Par exemple, il peut ne pas être nécessaire de générer des fichiers de traduction pendant les exécutions de test. Pour accélérer vos builds, vous pouvez désactiver la génération du fichier de traduction avec Live Unit Testing. Vous pouvez le faire en manipulant les fichiers projet.

Ajouter des remplacements Live Unit Testing

Si votre solution nécessite des étapes personnalisées de génération pour l’instrumentation (Live Unit Testing) qui ne sont pas nécessaires pour la génération non instrumentée « standard », vous pouvez ajouter du code à vos fichiers projet ou .targets pour vérifier la propriété BuildingForLiveUnitTesting et effectuer les étapes personnalisées avant et après la génération.

Par exemple, vous pouvez écrire l’exemple suivant pour ajouter une autre cible exécutée uniquement pour Live Unit Testing :

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

Vous pouvez utiliser la propriété BuildingForLiveUnitTesting pour désactiver certaines tâches qui ne doivent pas être exécutées pour les builds de test. Par exemple, Live Unit Testing définit <RunAnalyzers>false</RunAnalyzers> pour désactiver les analyseurs pour les tests.

Dépendances de test Live Unit Testing

Il est possible que tous les fichiers requis pour que les tests s’exécutent ne soient pas copiés. Live Unit Testing crée un dossier distinct où il exécute des tests. Cette disposition permet aux builds de se produire pendant l’exécution des tests, mais les fichiers du dossier de build ne sont pas tous copiés dans le dossier de test.

En règle générale, vous ajoutez les dépendances de test pour l’une des deux raisons suivantes :

• Vos tests dépendent des fichiers sous l’arborescence source. Par exemple, les tests examinent le contenu des fichiers resx ou peuvent lire certains fichiers de configuration.
• Vos tests dépendent de certaines bibliothèques qu’ils référencent. Par exemple, un test exécute un exécutable généré en tant que dépendance.

Dans les deux cas, Live Unit Testing par défaut ne copie pas ces fichiers pour réduire le nombre de fichiers qui doivent être copiés pour exécuter un test. Vous devez spécifier explicitement ces fichiers à l’aide de la propriété LiveUnitTestingTestDependency s’ils sont nécessaires pour une exécution de test. Par exemple, supposons que nous avons la disposition suivante :

SRC/
  CONSOLE_UTILITY/
  TEST_PROJECT/
ARTIFACTS/
  CONSOLE_UTILITY/NET472/DEBUG/
  TEST_PROJECT/NET472/DEBUG/

Par défaut, lorsque vous générez ces projets avec Live Unit Testing, il copie Artifacts/Test_Project uniquement dans le dossier de test. Pour ajouter des sources ou console_utility au dossier de test, ajoutez l’exemple suivant à test_project.csproj :

<LiveUnitTestingTestDependency Include=”$(RepoRoot)/Src/ConsoleUtility” />
<LiveUnitTestingTestDependency Include=”$(RepoRoot)/Artifacts/ConsoleUtility/net472/$(Configuration)/</LiveUnitTestingTestDependency” />

Démarrer, suspendre et arrêter

Pour activer Live Unit Testing, sélectionnez Tester>Live Unit Testing>Démarrer dans le menu du haut de Visual Studio. Une fois Live Unit Testing activé, les options disponibles dans le menu Live Unit Testing changent. À la place d’un seul élément, Start, se trouvent maintenant les options Pause et Stop :

• Pause permet de suspendre temporairement Live Unit Testing.

  Lorsque Live Unit Testing est suspendu, la visualisation de couverture n’apparaît pas dans l’éditeur, mais toutes les données collectées sont conservées. Pour réactiver Live Unit Testing, sélectionnez Continuer dans le menu Live Unit Testing. Live Unit Testing effectue le travail nécessaire pour rattraper toutes les modifications apportées lorsqu’il était interrompu et met à jour les glyphes en conséquence.

• L’option Stop arrête complètement Live Unit Testing. Live Unit Testing abandonne toutes les données qu’il a collectées.

Si vous démarrez Live Unit Testing dans une solution qui n’inclut pas de projet de test unitaire, les options Suspendre et Arrêter apparaissent dans le menu de Live Unit Testing, mais Live Unit Testing ne démarre pas. La fenêtre Output affiche un message qui commence par « No supported test adapters are referenced by this solution... ».

À tout moment, vous pouvez interrompre temporairement ou arrêter complètement Live Unit Testing. Vous souhaiterez peut-être effectuer ces actions, par exemple, si vous êtes en pleine refactorisation et que vous savez que vos tests seront incorrects pendant un certain temps.

Inclure et exclure des projets de test et des méthodes de test

Lorsque vous démarrez Live Unit Testing, la fenêtre de l’outil Live Unit Testing s’affiche et vous invite à sélectionner l’ensemble de tests que vous souhaitez que Live Unit Testing teste.

Pour les solutions plus petites où les tests unitaires prennent très peu de temps pour s’exécuter, sélectionnez Inclure tous les tests, ce qui fait que Live Unit Testing exécute tous les tests.

Pour des solutions plus volumineuses avec de nombreux projets de test, vous pouvez contrôler quels projets et méthodes individuelles d’un projet participent à Live Unit Testing en modifiant la playlist. Par exemple, si vous disposez d’une solution avec des centaines de projets de test, vous pouvez sélectionner un ensemble ciblé de projets de test à inclure dans Live Unit Testing.

Vous choisissez ce que Live Unit Testing doit exécuter en modifiant une playlist Live Unit Testing, une fonctionnalité qui fonctionne comme des playlists dans l’Explorateur de tests.

Il existe plusieurs façons de modifier la playlist Live Unit Testing :

• Fenêtre de l’outil Live Unit Testing
• Fenêtre de l’éditeur de code
• Explorateur de solutions
• Par programmation dans le code de test

Live Unit Testing enregistre l’état d’inclusion/d’exclusion en tant que paramètre utilisateur et le conserve quand une solution est fermée puis ouverte à nouveau.

Fenêtre de l’outil Live Unit Testing

Vous pouvez utiliser l’éditeur de playlist pour l’onglet Live Unit Testing pour inclure ou exclure des projets, des espaces de noms ou des classes de l’exécution. Sélectionnez Modifier la playlist dans la fenêtre Outil.

Vous pouvez sélectionner ou effacer les éléments d’arborescence pour inclure ou exclure des tests. Par exemple, si vous vérifiez un test unique, Live Unit Testing l’exécute sur les modifications. Si vous sélectionnez une classe, tous les tests de cette classe s’exécutent et tous les nouveaux tests ajoutés à cette classe s’exécutent également.

Fenêtre de l’éditeur de code

Vous pouvez utiliser la fenêtre de l’éditeur de code pour inclure ou exclure des méthodes de test. Cliquez avec le bouton droit sur la signature ou le corps de la méthode de test dans la fenêtre de l’éditeur de code, puis sélectionnez l’une des options suivantes :

• Live Unit Testing>Include <méthode sélectionnée>
• Live Unit Testing>Exclude <méthode sélectionnée>
• Live Unit Testing>Exclude All But <méthode sélectionnée>

Explorateur de solutions

Pour sélectionner les projets individuels dans les tests unitaires, suivez ces étapes une fois Live Unit Testing démarré :

1. Cliquez avec le bouton droit sur la solution dans l’Explorateur de solutions et sélectionnez Live Unit Testing>Exclure pour exclure toute la solution.
2. Cliquez avec le bouton droit sur chaque projet de test que vous voulez inclure dans les tests et sélectionnez Live Unit Testing>Inclure.

Par programmation dans le code de test

Vous pouvez appliquer l’attribut ExcludeFromCodeCoverageAttribute pour exclure par programme des méthodes, des classes ou des structures de la génération de couverture dans Live Unit Testing.

Utilisez les attributs suivants pour exclure des méthodes individuelles de Live Unit Testing :

• xUnit : [Trait("Category", "SkipWhenLiveUnitTesting")]
• NUnit : [Category("SkipWhenLiveUnitTesting")]
• MSTest : [TestCategory("SkipWhenLiveUnitTesting")]

Utilisez les attributs suivants pour exclure un assembly entier de tests de Live Unit Testing :

• xUnit : [assembly: AssemblyTrait("Category", "SkipWhenLiveUnitTesting")]
• NUnit : [assembly: Category("SkipWhenLiveUnitTesting")]
• MSTest : [assembly: TestCategory("SkipWhenLiveUnitTesting")]

Afficher la visualisation de la couverture

Une fois Live Unit Testing activé, il met à jour chaque ligne de code dans l’éditeur Visual Studio pour vous indiquer si le code que vous écrivez est couvert par des tests unitaires et si les tests qui le couvrent sont réussis.

L’image suivante montre des lignes de code avec des résultats positifs et négatifs aux tests, ainsi que des lignes de code qui ne sont pas couvertes par les tests. Les lignes avec une coche verte « ✓ » ne sont couvertes que par la réussite de tests. Les lignes avec une croix rouge « x » sont couvertes par un ou plusieurs tests défaillants. Les lignes avec un tiret bleu « ➖ » ne sont couvertes par aucun test.

La visualisation de la couverture Live Unit Testing est immédiatement mise à jour lorsque vous modifiez le code dans l’éditeur de code. Pendant le traitement des modifications, les modifications de visualisation indiquent que les données ne sont pas à jour en ajoutant une image de minuteur sous les symboles Réussite, Échec et Non couvert, comme l’illustre l’image suivante.

Obtenir des informations sur l’état des tests

En passant la souris sur le symbole de réussite ou d’échec dans la fenêtre de code, vous pouvez voir combien de tests ont atteint cette ligne. Pour afficher l’état des tests individuels, sélectionnez le symbole.

En plus de fournir les noms et les résultats des tests, l’info-bulle vous permet de réexécuter ou de déboguer l’ensemble de tests. Si vous sélectionnez un ou plusieurs des tests dans l’infobulle, vous pouvez également exécuter ou déboguer uniquement ces tests. Cette action vous permet de déboguer vos tests sans quitter la fenêtre de code.

Lors du débogage, en plus d’observer les points d’arrêt que vous pouvez avoir déjà définis, l’exécution du programme s’interrompt lorsque le débogueur exécute une méthode Assert qui retourne un résultat inattendu.

Lorsque vous passez la souris sur un test ayant échoué dans l’infobulle, celle-ci se développe pour fournir des informations supplémentaires sur l’échec, comme illustré dans l’image suivante. Pour accéder directement à un test ayant échoué, double-cliquez dessus dans l’info-bulle.

Lorsque vous accédez au test ayant échoué, Live Unit Testing indique visuellement dans la signature de méthode les tests qui :

• Ont réussi (indiqués par un bécher à moitié plein avec une coche verte « ✓ »).
• Ont échoué (indiqués par un bécher à moitié plein avec un signe « 🞩 » rouge).
• Ne sont pas impliqués dans Live Unit Testing (un bécher à moitié plein avec un signe « ➖ » bleu).

Les méthodes non testées ne sont pas identifiées par un symbole. L’image suivante montre les quatre types de méthodes.

Diagnostiquer et corriger les échecs des tests

À partir du test ayant échoué, vous pouvez facilement déboguer le code du produit, apporter des modifications et continuer à développer votre application. Étant donné que Live Unit Testing s’exécute en arrière-plan, il est inutile de l’arrêter et de le redémarrer pendant le débogage. Il vous suffit d’apporter les modifications et de continuer le cycle.

Par exemple, l’échec du test présenté dans l’image précédente est dû à une hypothèse incorrecte dans la méthode de test stipulant que les caractères non alphabétiques retournent true lorsqu’ils sont transmis à la méthode System.Char.IsLower. Une fois que vous avez corrigé la méthode de test, tous les tests doivent réussir. Vous n’avez pas besoin de suspendre ou d’arrêter Live Unit Testing.

Fenêtre Live Unit Testing

Live Unit Testing, similaire à l’Explorateur de tests, fournit une interface qui vous permet d’exécuter et de déboguer des tests, et d’analyser les résultats des tests. Lorsque Live Unit Testing est activé, l’état des tests unitaires dans l’Explorateur de tests est mis à jour immédiatement. Vous n’avez pas besoin d’exécuter explicitement les tests unitaires.

Quand Live Unit Testing n’est pas activé ou quand il est arrêté, Live Unit Testing affiche l’état des tests unitaires lors de la dernière exécution d’un test. Après un redémarrage de Live Unit Testing, une modification du code source est nécessaire pour réexécuter les tests.

Vous pouvez démarrer Live Unit Testing en sélectionnant Tester>Live Unit Testing>Démarrer dans le menu Visual Studio du haut. Vous pouvez également ouvrir la fenêtre Live Unit Testing à l’aide de Afficher>Autres fenêtres>Fenêtre Live Unit Testing.

Vous remarquerez peut-être dans la fenêtre Live Unit Testing que certains tests sont grisés. Par exemple, lorsque vous arrêtez et redémarrez Live Unit Testing, tous les test sont grisés dans la fenêtre Live Unit Testing, comme l’illustre l’image suivante.

Les résultats des tests grisés indiquent que le test ne faisait pas partie de la dernière exécution de Live Unit Testing. Les tests s’exécutent uniquement lorsqu’une modification du test ou des dépendances du test est détectée. Si aucune modification n’est apportée, cela évite d’exécuter inutilement le test. Dans ce cas, le résultat du test grisé est toujours « à jour », même s’il ne faisait pas partie de la dernière exécution.

Vous pouvez réexécuter tous les tests qui apparaissent estompés en apportant une modification de code.

Il existe certaines différences entre l’exécution automatique des tests et la mise à jour des résultats de test de Live Unit Testing et l’exécution explicite des tests à partir de l’Explorateur de tests. Ces différences incluent :

• L’exécution ou le débogage de tests à partir de la fenêtre Explorateur de tests exécute des fichiers binaires standard. Live Unit Testing exécute des fichiers binaires instrumentés.
• Live Unit Testing ne crée pas de domaine d’application pour exécuter des tests. Au lieu de cela, il exécute des tests à partir du domaine par défaut. Les tests exécutés depuis 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 de manière séquentielle. Dans la fenêtre Explorateur de tests, vous pouvez choisir d’exécuter plusieurs tests en parallèle.

Annuler les exécutions de test Live Unit Testing

Live Unit Testing continue d’exécuter des tests chaque fois que vous apportez des modifications au code. Si une exécution est en cours et que vous apportez davantage de modifications de code, Live Unit Testing met en file d’attente une autre exécution pendant qu’elle attend la fin de la première exécution.

Chaque fois que vous enregistrez des fichiers, Live Unit Testing annule la première exécution et planifie immédiatement l’exécution mise en file d’attente à la place. Ce processus permet d’utiliser des scénarios où la première exécution aurait pris beaucoup de temps.

Voir aussi

• Outils de test de code
• Blog sur Live Unit Testing
• FAQ Live Unit Testing