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.

  • 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/core/sdk>.

{
    "version": "1",
    "environments": [
        {
            "name": "linux dotnet-core-sdk-3.1",
            "type": "docker",
            "dockerImage": "mcr.microsoft.com/dotnet/core/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/core/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.

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

  2. 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
    
  3. Asegúrese de que está instalado el entorno de ejecución de .NET adecuado que las pruebas requieren. Puede descargar .NET para Windows.

  4. Prepare el entorno para las pruebas de depuración:

    1. Instale la SKU de Herramientas remotas en el entorno remoto.

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

  1. Asegúrese de que SSH está configurado y en ejecución.

  2. Instale fuse3 mediante un administrador de paquetes.

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

    Lista desplegable del entorno de pruebas remotas en el Explorador de pruebas

  • Después de seleccionar un entorno, las pruebas se detectan y se ejecutan en el nuevo entorno.

    Las pruebas se detectan y ejecutan en entornos remotos

  • Ahora puede ejecutar las pruebas en el remoto y depurarlas en entornos.

    Visualización de los resultados de pruebas de un entorno remoto en el Explorador de pruebas

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