Les projets de test MTP sont générés en tant qu’exécutables qui peuvent être exécutés (ou débogués) directement. Il n’existe aucune console ou commande supplémentaire exécutant des tests. L’application se termine par un code de sortie différent de zéro s’il existe une erreur, qui est typique pour la plupart des exécutables. Pour plus d’informations sur les codes de sortie connus, consultez les codes de sortie MTP.
La publication du project de test à l’aide de dotnet publish et l’exécution directe de l’application est un autre moyen d’exécuter vos tests. Par exemple, l’exécution du ./Contoso.MyTests.exe. Dans certains scénarios, il est également viable d’utiliser dotnet build pour produire l’exécutable, mais il peut y avoir des cas de périphérie à prendre en compte, comme AOT natif.
Utilisez dotnet run.
La commande dotnet run peut être utilisée pour générer et exécuter votre project de test. C’est le plus simple, bien que parfois lent, moyen d’exécuter vos tests. L'utilisation de dotnet run est pratique lorsque vous modifiez et exécutez des tests localement, car cela garantit que le project de test est reconstruit lorsque nécessaire.
dotnet run trouve également automatiquement le projet dans le répertoire actuel.
dotnet run --project Contoso.MyTests
Pour plus d’informations sur dotnet run, consultez dotnet run.
Utilisez dotnet exec.
La commande dotnet exec ou dotnet est utilisée pour exécuter (ou exécuter) un project de test déjà généré, il s’agit d’une alternative à l’exécution directe de l’application.
dotnet exec nécessite le chemin d'accès vers la dll du projet de test généré.
dotnet exec Contoso.MyTests.dll
ou
dotnet Contoso.MyTests.dll
Note
Fournir le chemin d’accès au fichier exécutable du projet de test (*.exe) entraîne une erreur :
Error:
An assembly specified in the application dependencies manifest
(Contoso.MyTests.deps.json) has already been found but with a different
file extension:
package: 'Contoso.MyTests', version: '1.0.0'
path: 'Contoso.MyTests.dll'
previously found assembly: 'S:\t\Contoso.MyTests\bin\Debug\net10.0\Contoso.MyTests.exe'
Pour plus d’informations sur dotnet exec, consultez dotnet exec.
Utilisez dotnet test.
À partir du SDK .NET 10, dotnet test dispose d’un mode MTP dédié. Sélectionnez MTP via global.json, ou utilisez la DOTNET_TEST_RUNNER variable d’environnement avec .NET 11 Preview 6 ou version ultérieure. Le mode dédié prend en charge les projets, les solutions, les modules de test générés et les types d’entrée supplémentaires dans les versions plus récentes du SDK.
dotnet test --test-modules Contoso.MyTests.dll
Pour en savoir plus sur la sélection de l’exécuteur de tests et la migration depuis le mode compatible avec VSTest, consultez Tester avec dotnet test.
Les tests MTP peuvent être exécutés (et débogués) dans Visual Studio, ils s’intègrent à l’Explorateur de tests et peuvent également être exécutés directement en tant que projet de démarrage.
Exécuter l’application avec Visual Studio
Les projets de test MTP sont générés en tant qu’exécutables et peuvent être exécutés directement. Cela exécute tous les tests dans l’exécutable donné, sauf si un filtre est fourni.
- Accédez au projet de test que vous souhaitez exécuter dans Explorateur de solutions, cliquez dessus avec le bouton droit, puis sélectionnez Définir comme projet de démarrage.
- Sélectionnez Debug>Démarrer sans débogage (ou utilisez Ctrl+F5) pour exécuter le projet de test sélectionné.
Une fenêtre de console s’affiche avec l’exécution et le résumé de votre série de tests.
Déboguer l’application directement dans Visual Studio
Le projet de test MTP peut être débogué directement. Pour déboguer tous les tests dans l’exécutable donné, sauf si un filtre est fourni :
- Accédez au projet de test que vous souhaitez exécuter dans Explorateur de solutions, cliquez dessus avec le bouton droit, puis sélectionnez Définir comme projet de démarrage.
- Définissez le point d’arrêt dans le test que vous souhaitez déboguer.
- Accédez à Debug>Démarrer le débogage (ou appuyez sur F5) pour déboguer le projet de test sélectionné.
Tous les tests sont exécutés jusqu’à ce que votre test avec un point d’arrêt soit atteint. Parcourez votre test pour le déboguer. Une fois le débogage terminé, l’application reprend l’exécution de tous les tests restants, sauf si vous l’arrêtez.
Utiliser l’Explorateur de tests
Pour exécuter un test, accédez à Test Explorer, sélectionnez le test (ou les tests) à exécuter. Sélectionnez-le avec le bouton droit, puis choisissez Exécuter. Comme pour déboguer un test, sélectionnez le test (ou les tests) dans Test Explorer, sélectionnez avec le bouton droit et choisissez Déboguer.
Note
La mise à jour automatique des tests sans construire le projet n'est pas disponible.
L'extension C# avec C# Dev Kit vous permet de déboguer/exécuter des tests dans Visual Studio code, ainsi que d'ajouter l'intégration à l'Explorateur de tests de Visual Studio Code.
Exécuter l’application avec Visual Studio Code
Les projets de test MTP sont générés en tant qu’exécutables et peuvent être exécutés directement. Cela exécute tous les tests dans l’exécutable donné, sauf si un filtre est fourni.
- Accédez à un fichier de test pour lequel vous souhaitez exécuter des tests.
- Utilisez Ctrl+F5 pour exécuter le project de test sélectionné. Si vous avez plusieurs projets, une fenêtre contextuelle vous demande de sélectionner celle à exécuter.
Une fenêtre de console s’affiche avec l’exécution et le résumé de votre série de tests.
Déboguer l’application directement dans Visual Studio Code
Les projets de test MTP sont générés en tant qu’exécutables et peuvent être exécutés directement. Cela exécute tous les tests dans l’exécutable donné, sauf si un filtre est fourni.
- Accédez à un fichier de test pour lequel vous souhaitez exécuter des tests.
- Utilisez F5 pour déboguer le project de test sélectionné. Si vous avez plusieurs projets, une fenêtre contextuelle vous demande de sélectionner celle à exécuter.
Conseil / Astuce
Il existe plusieurs autres façons d’exécuter un project dotnet à l’aide du DevKit C#, comme l’exécution à partir de solution explorer ou la création de configurations de lancement correspondantes. Elles sont spécifiées dans la documentation Visual Studio Code.
Lorsque le projet est exécuté, un onglet de sortie s’affiche avec l’exécution et le résumé de votre test.
Utiliser l’Explorateur de tests
Pour exécuter un test, accédez à Test Explorer, sélectionnez le test (ou les tests) à exécuter. Sélectionnez-le avec le bouton droit, puis choisissez Exécuter. Comme pour déboguer un test, sélectionnez le test (ou les tests) dans Test Explorer, sélectionnez avec le bouton droit et choisissez Déboguer.
Note
La mise à jour automatique des tests sans construire le projet n'est pas disponible.
Pour exécuter plusieurs projets de test en parallèle, appelez dotnet test une fois pour la solution au lieu d’ajouter une étape de pipeline pour chaque exécutable de test. Lorsque vous ajoutez un projet de test MTP à la solution, la même commande l’inclut sans modification de pipeline.
Exécuter une solution dans Azure Pipelines
Utilisez le sdk .NET 10 ou version ultérieure et MTP 1.7 ou version ultérieure. Tous les projets de test de la solution doivent prendre en charge MTP ; Les projets de test VSTest uniquement ne sont pas pris en charge dans ce mode. Pour connaître les versions antérieures du Kit de développement logiciel (SDK), consultez Exécuter des projets MTP en mode VSTest.
À la racine du référentiel, créez un fichier global.json avec le contenu suivant. Si le fichier existe déjà, ajoutez la section test et assurez-vous que ses paramètres SDK sont définis sur .NET 10 ou une version ultérieure.
{
"test": {
"runner": "Microsoft.Testing.Platform"
}
}
Pour les rapports TRX, chaque projet de test doit référencer Microsoft.Testing.Extensions.TrxReport, directement ou par le biais d’une configuration ou d’un profil sdk de test qui l’inclut. Pour plus d’informations, consultez les rapports de test (TRX) de Visual Studio.
Ajoutez le fichier suivant azure-pipelines.yml à votre référentiel. L’exemple suppose que Contoso.sln et global.json se trouvent à la racine du référentiel. Remplacez Contoso.sln par le chemin relatif du référentiel de votre solution.
trigger:
- main
pool:
vmImage: ubuntu-latest
steps:
- task: UseDotNet@2
displayName: Install .NET SDK
inputs:
packageType: sdk
version: 10.0.x
- task: DotNetCoreCLI@2
displayName: Run solution tests
inputs:
command: test
projects: Contoso.sln
arguments: --configuration Release --max-parallel-test-modules 4
workingDirectory: $(Build.SourcesDirectory)
publishTestResults: true
La DotNetCoreCLI@2 tâche invoque dotnet test une fois pour la solution. La commande restaure les dépendances, génère la solution et exécute ses modules de test MTP en parallèle. Par défaut, dotnet test s’exécute jusqu’à Environment.ProcessorCount modules à la fois. L’exemple utilise --max-parallel-test-modules 4 pour limiter la concurrence à quatre modules. Ajustez la limite pour qu’elle corresponde au processeur, à la mémoire et aux autres ressources de votre agent.
Important
Sélectionnez un fichier solution dans projects, et non un motif de fichier de projet tel que **/*.csproj. La tâche invoque dotnet test séparément pour chaque fichier mis en correspondance, l’un après l’autre. Un appel de solution unique permet à dotnet test de coordonner l’exécution parallèle dans l’ensemble de ses projets de test.
Le parallélisme au niveau du module est distinct de l’exécution parallèle de tests au sein d’un module. Pour configurer des tests parallèles au sein d’un assembly, utilisez les paramètres de votre framework de test. Pour MSTest, consultez ParallelizeAttribute.
Avec publishTestResults: true, la tâche ajoute --report-trx et --results-directory et publie les rapports dans l’onglet Tests de l’exécution du pipeline, même si les tests échouent. Un code de sortie différent de zéro dotnet test entraîne également l’échec de la tâche et du pipeline.
Note
La prise en charge de MTP DotNetCoreCLI@2 nécessite la version 2.263.0 ou ultérieure de la tâche. Conservez global.json dans le répertoire de travail de la tâche pour que la tâche et le SDK .NET sélectionnent MTP.
Exécuter une solution avec un script
Pour les versions de tâches sans prise en charge de MTP ou pour contrôler directement la commande CLI, utilisez un script et publiez les rapports TRX dans une étape distincte. Les mêmes .NET SDK, global.jsonet les exigences d’extension TRX s’appliquent.
trigger:
- main
pool:
vmImage: ubuntu-latest
steps:
- task: UseDotNet@2
displayName: Install .NET SDK
inputs:
packageType: sdk
version: 10.0.x
- task: CmdLine@2
displayName: Run solution tests
inputs:
script: >-
dotnet test --solution Contoso.sln
--configuration Release
--max-parallel-test-modules 4
--results-directory "$(Agent.TempDirectory)"
--report-trx
workingDirectory: $(Build.SourcesDirectory)
- task: PublishTestResults@2
displayName: Publish test results
condition: succeededOrFailed()
inputs:
testResultsFormat: VSTest
testResultsFiles: '**/*.trx'
searchFolder: $(Agent.TempDirectory)
failTaskOnFailedTests: true
failTaskOnMissingResultsFile: true
La succeededOrFailed() condition publie les résultats après une exécution de test réussie ou ayant échoué. Le code de sortie différent de zéro du script fait toujours échouer le pipeline. Pour éviter les écrasements de rapports entre les modules, n’affectez pas le même nom de fichier TRX à chaque module. Pour connaître les options de nommage et d’isolation, consultez les noms des fichiers de rapport.
Exécuter un fichier exécutable de test unique
Pour un projet de test unique, générez ou publiez le projet avant d’appeler directement son exécutable :
- task: CmdLine@2
displayName: "Run Contoso.MyTests"
inputs:
script: '.\Contoso.MyTests\bin\Debug\net10.0\Contoso.MyTests.exe'
