Configurer et utiliser Live Unit Testing

Pendant que vous développez une application, Live Unit Testing exécute automatiquement les tests unitaires affectés en arrière-plan et présente les résultats et la couverture du code en temps réel. Lorsque vous modifiez votre code, Live Unit Testing fournit des commentaires sur la façon dont vos modifications ont affecté les tests existants et indique si le nouveau 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 les données relatives à 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 dynamique de vos tests en réponse aux modifications de code.

Live Unit Testing est disponible uniquement dans l’édition Entreprise de Visual Studio pour les projets qui ciblent .NET Core ou .NET Framework.

Frameworks de test pris en charge

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 de leurs frameworks est également affichée. Les frameworks de test unitaire sont tous disponibles à partir de NuGet.org.

Infrastructure de test	Version minimale de l’adaptateur Visual Studio	Version minimale du framework
xUnit.net	xunit.runner.visualstudio version 2.2.0-beta3-build1187	xunit 1.9.2
NUnit	NUnit3TestAdapter version 3.5.1	NUnit version 3.5.0
MSTest	MSTest.TestAdapter 1.1.4-preview	MSTest.TestFramework 1.0.5-preview

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.

Dans certains cas, vous devrez peut-être restaurer explicitement les packages NuGet référencés par un projet pour que Live Unit Testing fonctionne. Deux options s'offrent à vous :

• Restaurez en effectuant une compilation explicite de la solution. Sélectionnez Build>Rebuild Solution dans le menu Visual Studio de niveau supérieur.
• Restaurez les packages dans la solution. Cliquez avec le bouton droit sur la solution et sélectionnez Restaurer des packages NuGet.

Configure

La première fois que vous démarrez Live Unit Testing pour une solution, un Assistant Installation 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 d'installation en accédant à Test>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 dépôt 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 d'où les fichiers doivent être copiés et où ils doivent être déplacé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 toutes les sources, fichiers binaires et outils. Dans les cas où le fichier solution n’est pas présent sous la racine du référentiel, la racine du référentiel peut avoir besoin d’ê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, à titre d'exemple, si vous devez normalement créer votre dépôt sous le lecteur C, la racine de l’espace de travail peut être ajustée à quelque chose comme 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 lors des builds doivent être exclus de la copie afin que les builds réguliers n'interfèrent pas avec les builds de tests en direct. En outre, la commande régulière nuget restore 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, telle que bin/ et obj/, n’est pas copiée dans l’espace de travail Live Unit Testing.

Pour les dépôts 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 d’ignorer personnalisé créé par Live Unit Testing une fois l’Assistant terminé s’affiche. C’est le fichier lutignore .

Note

Un fichier lutignore personnalisé est nécessaire pour certains référentiels Git, car il est possible de vérifier les fichiers dans le référentiel Git qui sont également ignorés par le fichier gitignore . Sans fichier lutignore personnalisé, Live Unit Testing ne copie pas ces fichiers, ce qui peut entraîner des échecs de génération.

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 la section où vous configurez les options de compilation.

• Générer des fichiers PDB : pour accélérer la compilation, Live Unit Testing ne génère pas de fichiers PDB pendant les compilations. Ces fichiers de symboles vous permettent d’accéder aux traces de la 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 votre solution ne parvient pas à être générée à l’aide de plusieurs processeurs, 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’endroit où vous configurez les options d’exécution des tests :

• 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.
• Utilisez 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/lire à partir des mêmes chemins de fichier.

Plus de configuration

Configurez Live Unit Testing en sélectionnant Options d’outils> dans la barre de menus visual Studio de niveau supérieur.

Dans le volet Options , développez la section All Settings>Test>Live Unit Testing .

Une fois les Tests Unitaires en Direct activés (consultez Démarrer, suspendre et arrêter les Tests Unitaires en Direct), vous pouvez rouvrir les options en sélectionnant Test>Tests Unitaires en Direct>Options.

Les options configurables sont les suivantes :

• Indique si Live Unit Testing s’interrompt lorsqu’une solution est générée et déboguée.

• Indique si Live Unit Testing s’interrompt lorsque la batterie d’un système tombe en dessous d’un seuil spécifié.

• 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.

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

• Niveau d’informations écrit dans la fenêtre Sortie Live Unit Testing.

  Les options incluent aucune journalisation (Aucun), uniquement les messages d'erreur (Erreur), les messages d'erreur et d'information (Informations, valeur par défaut) ou tous les détails (Détaillé).

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

  Pour capturer des messages détaillés du journal de MSBuild à partir de Live Unit Testing dans un fichier, définissez la variable d’environnement LiveUnitTesting_BuildLog au niveau utilisateur sur le nom du fichier qui contiendra 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 build 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 pour la compilation en vue de l'instrumentation (Live Unit Testing) qui ne sont pas requises pour la compilation « standard » non instrumentée, vous pouvez ajouter du code à votre projet ou aux fichiers .targets qui vérifie la propriété BuildingForLiveUnitTesting et effectue des étapes de pré-génération et post-génération personnalisées.

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 BuildingForLiveUnitTesting propriété 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 dans les tests.

Dépendances de test Live Unit Testing

Il est possible que tous les fichiers ne soient pas copiés qui sont requis pour que les tests s’exécutent. 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 pas tous les fichiers du dossier de build sont 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.

Note

Les dépendances de test doivent exister dans le répertoire spécifié en tant que Repository Root dans l’assistant de configuration.

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 LiveUnitTestingTestDependency propriété 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 des 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 Test>Live Unit Testing>Start dans le menu Visual Studio de niveau supérieur. Lorsque Live Unit Testing est activé, les options disponibles dans le menu Live Unit Testing passent d’un seul élément, Démarrer, à Suspendre et Arrêter :

• Pause suspend temporairement les tests unitaires en direct.

  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 reprendre 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 effectuées pendant qu’elle a été suspendue et met à jour les glyphes de manière appropriée.

• Arrête complètement les tests unitaires en direct. Live Unit Testing ignore toutes les données qu’elle a collectées.

Si vous démarrez Live Unit Testing dans une solution qui n’inclut pas de projet de test unitaire , les options Pause et Arrêt apparaissent dans le menu Live Unit Testing , mais Live Unit Testing ne démarre pas. La fenêtre Sortie affiche un message qui commence par : « Aucun adaptateur de test pris en charge n'est référencé par cette solution... »

À tout moment, vous pouvez suspendre temporairement ou arrêter complètement Live Unit Testing. Vous souhaiterez peut-être effectuer ces actions, par exemple, si vous êtes au milieu de la refactorisation et savez que vos tests seront rompus 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 tester par Live Unit Testing.

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 rend Live Unit Testing exécuter 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 avez une solution avec des centaines de projets de test, vous pouvez sélectionner un ensemble ciblé de projets de test pour participer à 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 include/exclude en tant que paramètre utilisateur et se rappelle qu’une solution est fermée et rouverte.

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 évaluez un test unique, Live Unit Testing l'exécute lorsque des modifications sont apportées. 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 individuelles. 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>Inclure <la méthode> sélectionnée
• Live Unit Testing>Exclure <la méthode> sélectionnée
• Live Unit Testing>Exclure tout sauf la< méthode> sélectionnée

Explorateur de solutions

Pour sélectionner les projets individuels dans les tests unitaires, procédez comme suit après le démarrage de Live Unit Testing :

1. Cliquez avec le bouton droit sur la solution dans l’Explorateur de solutions, puis sélectionnez Live Unit Testing>Exclude pour exclure l’ensemble de la solution.
2. Cliquez avec le bouton droit sur chaque projet de test que vous souhaitez inclure dans les tests et sélectionnez Live Unit Testing>Include.

Par programmation dans le code de test

Vous pouvez appliquer l'attribut ExcludeFromCodeCoverageAttribute pour exclure par programmation les méthodes, les classes ou les structures du rapport 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 l’ensemble d’un assembly 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 tests réussis et défaillants, ainsi que des lignes de code qui ne sont pas couvertes par des tests. Les lignes avec un vert « ✓ » ne sont couvertes que par la réussite de tests. Les lignes avec un « x » rouge indiquent un ou plusieurs tests échoués. Les lignes avec un « ➖ » bleu ne sont pas couvertes par aucun test.

La visualisation de couverture Live Unit Testing est mise à jour immédiatement lorsque vous modifiez du code dans l’éditeur de code. Lors du traitement des modifications, la visualisation change pour indiquer que les données ne sont pas à jour en ajoutant une image de minuteur arrondie sous les symboles passés, défaillants et non couverts, comme l’illustre l’image suivante.

Obtenir des informations sur l’état du test

En pointant sur le symbole passé ou défaillant dans la fenêtre de code, vous pouvez voir le nombre de tests qui atteignent 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’info-bulle, vous pouvez également exécuter ou déboguer uniquement ces tests. Cette action vous permet de déboguer vos tests sans avoir à quitter la fenêtre de code.

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

Lorsque vous pointez sur un test ayant échoué dans l’info-bulle, il s’étend pour fournir plus d’informations 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 :

• Passé (indiqué par un beaker demi-complet avec un vert « ✓ »).
• Échec (indiqué par un beaker demi-complet avec un «🞩 » rouge).
• Ne sont pas impliqués dans Live Unit Testing (indiqué par un beaker demi-complet avec un « ➖ » bleu).

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

Diagnostiquer et corriger les échecs de test

À 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, vous n’avez pas besoin d’arrêter et de redémarrer Live Unit Testing pendant le débogage, la modification et le cycle de poursuite.

Par exemple, l’échec de test indiqué dans l’image précédente a été provoqué par une hypothèse incorrecte dans la méthode de test que les caractères non anhabétiques retournent true lorsqu’ils sont passés à la System.Char.IsLower méthode. Après avoir 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.

Lorsque Live Unit Testing n’est pas activé ou est arrêté, Live Unit Testing affiche l’état des tests unitaires la dernière fois qu’un test a été exécuté. Après avoir redémarré 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 Test>Live Unit Testing>Démarrer dans le menu Visual Studio de niveau supérieur. Vous pouvez également ouvrir la fenêtre Live Unit Testing à l’aide de Affichage>Autres fenêtres>Live Unit Testing Window.

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

Les résultats des tests estompés indiquent que le test n'était pas inclus dans la dernière série de tests unitaires en direct. Les tests s’exécutent uniquement lorsqu’une modification apportée au test ou aux dépendances du test est détectée. S’il n’y a aucune modification, il évite inutilement d’exécuter le test. Dans ce cas, le résultat du test grisé est toujours « à jour », bien qu'il n'ait pas fait partie de la dernière exécution.

Vous pouvez réexécuter tous les tests qui apparaissent en grisé en modifiant le code.

Il existe des différences entre Live Unit Testing qui s’exécutent automatiquement et mettent à jour les résultats des tests et exécutent explicitement des tests à partir de l’Explorateur de tests. Ces différences sont les suivantes :

• 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 à partir de la fenêtre Explorateur de tests créent un domaine d’application.
• Live Unit Testing exécute des tests dans chaque assembly de test séquentiellement. Dans la fenêtre Explorateur de tests, vous pouvez choisir d’exécuter plusieurs tests en parallèle.

Annuler les exécutions de tests de Live Unit Testing

Live Unit Testing continue d’exécuter des tests chaque fois que vous apportez des modifications de 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 du Live Unit Testing
• Faq sur les tests unitaires en direct