Pruebas remotas (versión preliminar experimental)
Las pruebas remotas permiten a los desarrolladores conectar Visual Studio 2022 a entornos remotos para ejecutar y depurar pruebas. Esta funcionalidad es útil para los desarrolladores multiplataforma que implementan código en varios entornos de destino diferentes, como distintos sistemas operativos Windows o Linux. Por ejemplo, normalmente un desarrollador inserta cambios en una canalización de CI para obtener comentarios de una prueba que se ejecuta en Linux. Con la característica de pruebas remotas, puede conectar el Explorador de pruebas a un entorno remoto para ejecutar pruebas de Linux directamente desde Visual Studio.
Requisitos
Los siguientes requisitos se aplican a la versión experimental de las pruebas remotas:
Debe ejecutar Visual Studio 2022 Update 17.0 Preview 3 o posterior.
Actualmente, la característica solo admite pruebas de .NET y .NET Framework.
- Si le interesa la compatibilidad con pruebas remotas para otros lenguajes, envíe una sugerencia o vote a favor de una sugerencia existente. Compatibilidad con pruebas remotas de C++.
Actualmente, la característica admite imágenes de Windows, Ubuntu y Debian en el entorno remoto. Para .NET Framework, solo se admiten entornos remotos de Windows.
Actualmente, la mayor parte del aprovisionamiento del entorno se deja a la especificación del usuario.
El usuario debe instalar las dependencias necesarias en el entorno de destino. Por ejemplo, si las pruebas tienen como destino .NET 6.0, debe asegurarse de que el contenedor tenga instalado .NET 6.0 a través del Dockerfile. Puede haber una solicitud para instalar .NET Core en el entorno remoto, lo cual es necesario para ejecutar y detectar pruebas de forma remota.
Planee la supervisión del estado de conexión al entorno remoto a través del panel Salida>Pruebas.
Por ejemplo, si el contenedor se detiene, aparece un mensaje en el panel Salidas>Pruebas. Es posible que la característica no detecte todos los escenarios, así que compruebe la salida si parece que la conexión se ha perdido. En concreto, si el panel Salida no se ha establecido en "Prueba", es posible que no vea inmediatamente el mensaje. Si la conexión se ha perdido, puede usar la lista desplegable de entornos en el Explorador de pruebas para volver a establecer la conexión con el entorno local y, luego, seleccionar de nuevo el entorno remoto para reconectarse.
Configuración del entorno de pruebas remotas
Los entornos se especifican mediante el archivo testenvironments.json en la raíz de la solución. La estructura de archivos json implementa el esquema siguiente:
{
"version": "1", // value must be 1
"environments": [
{ "name": "<unique name>", ... },
...
]
}
Propiedades de un entorno en testenvironments.json
El archivo testenvironments.json tiene las siguientes propiedades de entorno.
Propiedad | Tipo | Description |
---|---|---|
name |
cadena | Nombre de entorno descriptivo que aparece en el Explorador de pruebas. Debe ser único en un archivo testEnvironments.json. |
localRoot |
cadena | [Opcional] Ruta de acceso en la máquina local (absoluta o relativa al directorio de la solución), que se proyecta en el entorno remoto. Si no se especifica, el valor predeterminado es la raíz del repositorio dentro del contexto de un repositorio de Git (en Visual Studio 2022, versión 17.1 y posteriores). Fuera de un repositorio de Git, el valor predeterminado es el directorio de la solución. |
type |
enum | Indica el tipo de entorno remoto. El valor puede ser docker , wsl o ssh . |
dockerImage |
cadena | Nombre de una imagen de Docker que se cargará en un entorno de Docker. Este valor es necesario si el type del entorno es docker . |
dockerFile |
cadena | Ruta de acceso a un archivo de Docker, relativa al directorio de la solución, para compilar una imagen y cargarla en un entorno de Docker. Este valor es necesario si el type del entorno es docker . |
wslDistribution |
cadena | Nombre de la distribución de WSL local en la que se va a ejecutar el entorno de prueba. Este valor es necesario si el type del entorno es wsl . |
remoteUri |
cadena | Un URI que especifica la conexión a la máquina remota. Por ejemplo, ssh://user@hostname:22 . Este valor es necesario si el type del entorno es ssh . |
Nota:
Debe especificar la propiedad dockerImage
o dockerFile
, pero no ambas.
Conexiones de contenedor local
Para conectarse a un contenedor que se ejecuta localmente, debe tener Docker Desktop en la máquina local. Opcionalmente, habilite la integración con WSL2 para mejorar el rendimiento.
Para un Dockerfile, el entorno se puede especificar en el archivo testEnvironments.json en la raíz de la solución. Usa las siguientes propiedades:
{
"name": "<name>",
"type": "docker",
"dockerImage": "<docker image tag>",
}
En el ejemplo siguiente se muestra el archivo testenvironments.json para una imagen de contenedor local denominada <mcr.microsoft.com/dotnet/sdk>
.
{
"version": "1",
"environments": [
{
"name": "linux dotnet-sdk-5.0",
"type": "docker",
"dockerImage": "mcr.microsoft.com/dotnet/sdk"
}
]
}
En el ejemplo a continuación se muestra un Dockerfile para ejecutar pruebas que tienen .NET 5.0 como destino. La segunda línea se asegura de que el depurador pueda conectarse y ejecutarse en el contenedor.
FROM mcr.microsoft.com/dotnet/sdk:5.0
RUN wget https://aka.ms/getvsdbgsh && \
sh getvsdbgsh -v latest -l /vsdbg
El contenedor debe tener una imagen integrada en la máquina local. Puede compilar un contenedor con el comando docker build -t <docker image name> -f <path to Dockerfile> .
. Asegúrese de incluir el período .
al final del comando.
En el ejemplo siguiente se muestra el uso de la propiedad dockerFile
en lugar de la propiedad dockerImage
.
{
"version": "1",
"environments": [
{
"name": "GitServiceUnix",
"type": "docker",
"dockerFile": "Dockerfile.test"
}
]
}
Conexiones WSL2 locales
Para ejecutar pruebas de forma remota en WSL2, debe habilitar la integración con WSL2 en la máquina local.
El entorno se puede especificar en el archivo testEnvironments.json en la raíz de la solución mediante el esquema siguiente. Reemplace el valor <Ubuntu>
de la propiedad wslDistribution
por la instalación de la distribución de WSL2.
{
"version": "1",
"environments": [
{
"name": "WSL-Ubuntu",
"type": "wsl",
"wslDistribution": "Ubuntu"
}
]
}
Conexiones SSH
Puede agregar o quitar conexiones SSH en Herramientas > Opciones > Multiplataforma > Administrador de conexiones. Seleccione Agregar para escribir el nombre de host, el puerto y las credenciales que necesite.
El entorno se puede especificar en el archivo testEnvironments.json en la raíz de la solución mediante el esquema siguiente. Reemplace el valor <ssh://user@hostname:22>
de la propiedad remoteUri
por el valor SSH.
{
"version": "1",
"environments": [
{
"name": "ssh-remote",
"type": "ssh",
"remoteUri": "ssh://user@hostname:22"
}
]
}
Requisitos previos para un entorno de Windows remoto
Revise los siguientes requisitos previos para un entorno remoto de Windows.
Asegúrese de que el Sistema de archivos proyectados de Windows esté habilitado en el equipo remoto. Puede ejecutar el siguiente código desde una ventana de PowerShell de administración para habilitarlo:
Enable-WindowsOptionalFeature -Online -FeatureName Client-ProjFS -NoRestart
Reinicie el entorno según sea necesario.
Asegúrese de que SSH está configurado. Puede revisar los pasos descritos en Instalación de OpenSSH. Inicie el servidor SSH mediante la ejecución del siguiente comando desde una ventana de PowerShell de administración:
Start-Service sshd
Asegúrese de que está instalado el entorno de ejecución de .NET adecuado que las pruebas requieren. Puede descargar .NET para Windows.
Prepare el entorno para las pruebas de depuración:
Instale la SKU de Herramientas remotas en el entorno remoto.
Inicie el depurador remoto como administrador y asegúrese de que el usuario de Visual Studio tenga permisos para conectarse.
Requisitos previos para un entorno de Linux remoto
Revise los siguientes requisitos previos para un entorno remoto de Linux.
Asegúrese de que SSH está configurado y en ejecución.
Instale
fuse3
mediante un administrador de paquetes.Asegúrese de que el entorno de ejecución de .NET adecuado que las pruebas requieren está instalado en el entorno remoto de Linux.
Uso del Explorador de pruebas para ejecutar y depurar pruebas remotas
Aquí se muestra cómo puede usar el Explorador de pruebas para ejecutar y depurar las pruebas de entorno remoto.
El entorno activo se selecciona a través de una lista desplegable de la barra de herramientas del Explorador de pruebas. Actualmente, solo un entorno de prueba puede estar activo a la vez.
Después de seleccionar un entorno, las pruebas se detectan y se ejecutan en el nuevo entorno.
Ahora puede ejecutar las pruebas en el remoto y depurarlas en entornos.
El Explorador de pruebas puede solicitarle que instale requisitos previos del entorno que faltan e intentar instalar las dependencias faltantes. Sin embargo, la mayor parte del aprovisionamiento del entorno remoto se deja a la especificación del usuario.