Tests à distance (préversion expérimentale)
Les tests à distance permettent aux développeurs de connecter Visual Studio 2022 à des environnements distants pour exécuter et déboguer des tests. Cette fonctionnalité est utile pour les développeurs multiplateformes qui déploient du code sur plusieurs environnements cibles distincts, par exemple les différents systèmes d’exploitation Windows ou Linux. Par exemple, un développeur envoie normalement des modifications à un pipeline d'intégration continue pour obtenir un retour d'information d'un test exécuté sous Linux. Avec la fonctionnalité de test à distance, vous pouvez exécuter des tests Linux directement à partir de Visual Studio en connectant l'Explorateur de tests à un environnement distant.
Spécifications
Les exigences suivantes s'appliquent à la version expérimentale des tests à distance :
Vous devez exécuter Visual Studio 2022 Update 17.0 Preview 3 ou version ultérieure.
Pour le moment, cette fonctionnalité prend uniquement en charge les tests .NET et .NET Framework.
- Si vous souhaitez prendre en charge les tests à distance pour d'autres langues, vous pouvez déposer une suggestion ou donner votre avis sur suggestion existante. Prise en charge des tests à distance C++.
Actuellement, la fonctionnalité prend en charge les images Windows, Ubuntu et Debian sur l'environnement distant. Pour .NET Framework, seuls les environnements Windows distants sont pris en charge.
L'essentiel de l'approvisionnement de l'environnement est laissé à l'appréciation de l'utilisateur.
L'utilisateur doit installer les dépendances nécessaires dans votre environnement cible. Par exemple, si vos tests ciblent .NET 6.0, vous devez vérifier que .NET 6.0 est installé sur le conteneur via votre fichier Dockerfile. Une invite peut éventuellement s'afficher pour l'installation de .NET Core sur l'environnement distant, car il est nécessaire à l'exécution et à la découverte des tests à distance.
Prévoyez de surveiller l'état de votre connexion à l'environnement distant à l'aide du volet Sortie>Tests.
Par exemple, si le conteneur s'arrête, un message s'affiche dans le volet Sortie>Tests. La fonctionnalité peut ne pas détecter tous les scénarios. Prévoyez donc de vérifier votre sortie si elle ressemble à la perte de la connexion. En particulier, si le volet Sortie n'est pas défini sur « Test », vous ne voyez peut-être pas immédiatement le message. Si la connexion est perdue, vous pouvez utiliser la liste déroulante de l'environnement dans l'Explorateur de tests pour rétablir la connexion à votre environnement local, puis sélectionner à nouveau l'environnement distant pour vous reconnecter.
Configurer l’environnement des tests à distance
Les environnements sont spécifiés à l'aide du fichier testenvironments.json à la racine de votre solution. La structure de fichiers json implémente le schéma suivant :
{
"version": "1", // value must be 1
"environments": [
{ "name": "<unique name>", ... },
...
]
}
Propriétés d’un environnement dans testenvironments.json
Le fichier testenvironments.json a les propriétés d'environnement suivantes.
Propriété | Type | Description |
---|---|---|
name |
string | Nom d’environnement convivial qui apparaît dans l’Explorateur de tests. Il doit être unique dans un fichier testEnvironments.json. |
localRoot |
string | [Facultatif] Chemin sur la machine locale (absolu ou relatif vers le répertoire de la solution), qui est projeté dans l’environnement distant. Si elle n'est pas spécifiée, la valeur par défaut est la racine du dépôt dans le contexte d'un dépôt Git (sur Visual Studio 2022 version 17.1 et ultérieure). En dehors d'un référentiel Git, la valeur par défaut est le répertoire de solution. |
type |
enum | Indique le type de l’environnement distant. La valeur peut être docker , wsl ou ssh . |
dockerImage |
string | Nom d’une image Docker à charger dans un environnement Docker. Cette valeur est requise si l'environnement type est docker . |
dockerFile |
string | Chemin vers un fichier Docker, par rapport au répertoire de la solution, pour générer une image et la charger dans un environnement Docker. Cette valeur est requise si l'environnement type est docker . |
wslDistribution |
string | Nom de la distribution WSL locale dans laquelle exécuter l’environnement de test. Cette valeur est requise si l'environnement type est wsl . |
remoteUri |
string | URI qui spécifie la connexion à la machine distante. Par exemple : ssh://user@hostname:22 . Cette valeur est requise si l'environnement type est ssh . |
Remarque
Vous devez spécifier la propriété dockerFile
ou dockerImage
, mais pas les deux propriétés.
Connexions de conteneur locales
Pour vous connecter à un conteneur s’exécutant localement, vous devez disposer de Docker Desktop sur votre machine locale. Vous pouvez éventuellement activer l’intégration WSL2 pour améliorer les performances.
Pour un fichier Dockerfile, l'environnement peut être spécifié dans le fichier testEnvironments.json à la racine de votre solution. Elle utilise les propriétés suivantes :
{
"name": "<name>",
"type": "docker",
"dockerImage": "<docker image tag>",
}
L'exemple suivant montre le fichier testenvironments.json pour une image conteneur locale nommée <mcr.microsoft.com/dotnet/sdk>
.
{
"version": "1",
"environments": [
{
"name": "linux dotnet-sdk-5.0",
"type": "docker",
"dockerImage": "mcr.microsoft.com/dotnet/sdk"
}
]
}
L’exemple suivant montre un fichier Dockerfile pour l’exécution de tests ciblant .NET 5.0. La deuxième ligne permet de vérifier que le débogueur peut se connecter et s’exécuter dans votre conteneur.
FROM mcr.microsoft.com/dotnet/sdk:5.0
RUN wget https://aka.ms/getvsdbgsh && \
sh getvsdbgsh -v latest -l /vsdbg
Le conteneur doit disposer d’une image générée sur votre machine locale. Vous pouvez générer un conteneur avec la commande docker build -t <docker image name> -f <path to Dockerfile> .
. Veillez à inclure la période .
à la fin de la commande.
L'exemple suivant montre l'utilisation de la propriété dockerFile
au lieu de la propriété dockerImage
.
{
"version": "1",
"environments": [
{
"name": "GitServiceUnix",
"type": "docker",
"dockerFile": "Dockerfile.test"
}
]
}
Connexions WSL2 locales
Pour exécuter des tests à distance sur WSL2, vous devez activer l’intégration WSL2 sur votre machine locale.
L'environnement peut être spécifié dans le fichier testEnvironments.json à la racine de votre solution à l'aide du schéma suivant. Remplacez la valeur <Ubuntu>
de la propriété wslDistribution
par votre installation de la distribution WSL2.
{
"version": "1",
"environments": [
{
"name": "WSL-Ubuntu",
"type": "wsl",
"wslDistribution": "Ubuntu"
}
]
}
Connexions SSH
Vous pouvez ajouter ou supprimer des connexions SSH dans Outils > Options > Multiplateforme > Gestionnaire des connexions. Sélectionnez Ajouter pour entrer le nom d'hôte, le port et les informations d'identification dont vous avez besoin.
L'environnement peut être spécifié dans le fichier testEnvironments.json à la racine de votre solution à l'aide du schéma suivant. Remplacez la valeur <ssh://user@hostname:22>
de la propriété remoteUri
par votre valeur SSH.
{
"version": "1",
"environments": [
{
"name": "ssh-remote",
"type": "ssh",
"remoteUri": "ssh://user@hostname:22"
}
]
}
Prérequis pour un environnement Windows distant
Passez en revue les conditions préalables suivantes pour un environnement Windows distant.
Assurez-vous que le système de fichiers projeté de Windows est activé sur la machine distante. Vous pouvez exécuter le code suivant à partir d'une fenêtre PowerShell d'administration pour l'activer :
Enable-WindowsOptionalFeature -Online -FeatureName Client-ProjFS -NoRestart
Redémarrez l'environnement en fonction des besoins.
Vérifiez que SSH est bien configuré. Vous pouvez passer en revue les étapes dans Installer OpenSSH. Démarrez le serveur SSH en exécutant la commande suivante à partir d’une fenêtre PowerShell d’administrateur :
Start-Service sshd
Vérifiez que le runtime .NET approprié requis par vos tests est bien installé. Vous pouvez télécharger .NET pour Windows.
Préparez l'environnement pour le débogage des tests :
Installez la référence SKU des outils à distance sur l'environnement distant.
Démarrez le débogueur distant en tant qu'administrateur et vérifiez que l'utilisateur Visual Studio dispose des autorisations nécessaires pour se connecter.
Prérequis pour un environnement Linux distant
Passez en revue les conditions préalables suivantes pour un environnement Linux distant.
Vérifiez que SSH est configuré et en cours d’exécution.
Installez
fuse3
à l'aide d'un gestionnaire de package.Vérifiez que le runtime .NET approprié requis par vos tests est installé sur l'environnement Linux distant.
Utiliser l’Explorateur de tests pour exécuter et déboguer des tests à distance
Voici comment utiliser l'Explorateur de tests pour exécuter et déboguer vos tests d'environnement distant.
L’environnement actif est sélectionné via une liste déroulante dans la barre d’outils de l’Explorateur de tests. Pour le moment, un seul environnement de test peut être actif à la fois.
Une fois que vous avez sélectionné un environnement, les tests sont découverts et exécutés dans le nouvel environnement.
Vous pouvez désormais exécuter et déboguer vos tests dans les environnements distants !
L'Explorateur de tests peut vous inviter à installer certains prérequis d'environnement manquants et à tenter d'installer des dépendances manquantes. Cependant, l'essentiel de l'approvisionnement de l'environnement distant dépend des spécifications de l'utilisateur.