Teste remoto (versão prévia experimental)

Artigo
11/08/2023

O teste remoto permite que os desenvolvedores conectem o Visual Studio 2022 a ambientes remotos para executar e depurar testes. Essa funcionalidade é útil para desenvolvedores multiplataforma que implantam código em vários ambientes de destino diferentes, como diferentes sistemas operacionais Windows ou Linux. Por exemplo, normalmente, um desenvolvedor enviar alterações por push para um pipeline de CI para obter comentários de um teste em execução no Linux. Com o recurso de teste remoto, você pode executar testes do Linux diretamente do Visual Studio conectando o Gerenciador de Testes a um ambiente remoto.

Requisitos

Os seguintes requisitos se aplicam à versão experimental do teste remoto:

Você precisa estar executando o Visual Studio 2022 Atualização 17.0 Preview 3 ou posterior.
Atualmente, o recurso oferece suporte apenas a testes do .NET e do .NET Framework.
- Se você estiver interessado em suporte a testes remotos para outras linguagens, registre uma sugestão ou vote a favor de uma sugestão existente. Suporte a testes remotos em C++.
Atualmente, o recurso só dá suporte a imagens do Windows, Ubuntu e Debian no ambiente remoto. Para o .NET Framework, há suporte somente a ambientes remotos do Windows.
Atualmente, a maior parte do provisionamento do ambiente é deixada para a especificação do usuário.

O usuário precisa instalar as dependências necessárias no ambiente de destino. Por exemplo, se os testes forem direcionados ao .NET 6.0, você precisará verificar se o contêiner tem o .NET 6.0 instalado por meio do Dockerfile. Pode haver um prompt para instalar o .NET Core no ambiente remoto, que é necessário para executar e descobrir testes remotamente.
Planeje monitorar o status da conexão com o ambiente remoto usando o painel Saída>Testes.

Por exemplo, se o contêiner for interrompido, uma mensagem será exibida no painel Saída>Testes. O recurso pode não detectar todos os cenários, portanto, planeje verificar sua saída se parece que a conexão foi perdida. Em particular, se o painel Saída não estiver definido como "Teste", talvez você não veja a mensagem imediatamente. Se a conexão for perdida, você poderá usar a lista suspensa ambiente no Gerenciador de Testes para definir a conexão de volta para seu ambiente local e, em seguida, selecionar o ambiente remoto novamente para reconectar.

Configurar o ambiente de teste remoto

Os ambientes são especificados usando o arquivo testenvironments.json na raiz da solução. A estrutura de arquivos json implementa o seguinte esquema:

{
    "version": "1", // value must be 1
    "environments": [
        { "name": "<unique name>", ... },
        ...
    ]
}

Propriedades de um ambiente em testenvironments.json

O arquivo testenvironments.json tem as propriedades de ambiente a seguir.

Propriedade	Type	Descrição
`name`	string	Nome de ambiente amigável que aparece no Gerenciador de Testes. Ele precisa ser exclusivo em um arquivo testEnvironments.json.
`localRoot`	string	[Opcional] Caminho no computador local (absoluto ou relativo ao diretório da solução), que é projetado para o ambiente remoto. Se não for especificado, esse padrão será a raiz do repositório no contexto de um repositório git (no Visual Studio 2022 versão 17.1 e superior). Fora de um repositório git, o valor padrão é o diretório da solução.
`type`	enumeração	Indica o tipo de ambiente remoto. O valor pode ser `docker`, `wsl` ou `ssh`.
`dockerImage`	string	Nome de uma imagem do Docker a ser carregada em um ambiente do Docker. Esse valor será necessário se o ambiente `type` for `docker`.
`dockerFile`	string	Caminho para um arquivo do Docker, em relação ao diretório da solução, para criar uma imagem e carregar em um ambiente do Docker. Esse valor será necessário se o ambiente `type` for `docker`.
`wslDistribution`	string	Nome da distribuição WSL local na qual o ambiente de teste deve ser executado. Esse valor será necessário se o ambiente `type` for `wsl`.
`remoteUri`	string	Um uri que especifica a conexão com o computador remoto. Por exemplo, `ssh://user@hostname:22`. Esse valor será necessário se o ambiente `type` for `ssh`.

Observação

Você precisa especificar a propriedade dockerImage ou dockerFile, mas não ambas as propriedades.

Conexões de contêiner local

Para se conectar a um contêiner em execução localmente, você deve ter o Docker Desktop em seu computador local. Opcionalmente, habilite a integração do WSL2 para melhorar o desempenho.

Para um Dockerfile, o ambiente pode ser especificado no arquivo testEnvironments.json na raiz da sua solução. Ela usa as propriedades a seguir:

{
    "name": "<name>",
    "type": "docker",
    "dockerImage": "<docker image tag>",
}

O exemplo a seguir mostra o arquivo testenvironments.json para uma imagem de contêiner local chamada <mcr.microsoft.com/dotnet/sdk>.

{
    "version": "1",
    "environments": [
        {
            "name": "linux dotnet-sdk-5.0",
            "type": "docker",
            "dockerImage": "mcr.microsoft.com/dotnet/sdk"
        }
    ]
}

O exemplo a seguir mostra um Dockerfile para executar testes direcionados ao .NET 5.0. A segunda linha garante que o depurador possa se conectar e executar em seu contêiner.

FROM mcr.microsoft.com/dotnet/sdk:5.0

RUN wget https://aka.ms/getvsdbgsh && \
    sh getvsdbgsh -v latest  -l /vsdbg

O contêiner deve ter uma imagem interna no computador local. Você pode criar um contêiner com o comando docker build -t <docker image name> -f <path to Dockerfile> .. Certifique-se de incluir o ponto . no final do comando.

O exemplo a seguir mostra o uso da propriedade dockerFile em vez da propriedade dockerImage.

{
    "version": "1",
    "environments": [
        {
            "name": "GitServiceUnix",
            "type": "docker",
            "dockerFile": "Dockerfile.test"
        }
    ]
}

Conexões WSL2 locais

Para executar testes remotamente no WSL2, você deve habilitar a integração do WSL2 em seu computador local.

O ambiente pode ser especificado no arquivo testEnvironments.json na raiz da sua solução usando o esquema a seguir. Substitua o valor <Ubuntu> da propriedade wslDistribution com a sua instalação da Distribuição WSL2.

{
    "version": "1",
    "environments": [
        {
            "name": "WSL-Ubuntu",
            "type": "wsl",
            "wslDistribution": "Ubuntu"
        }
    ]
}

Conexões SSH

Você pode adicionar ou remover conexões SSH em Ferramentas > Opções > Multiplataforma > Gerenciador de Conexões. Selecione Adicionar para inserir o nome do host, a porta e as credenciais necessárias.

O ambiente pode ser especificado no arquivo testEnvironments.json na raiz da sua solução usando o esquema a seguir. Substitua o valor <ssh://user@hostname:22> da propriedade remoteUri pelo seu valor de SSH.

{
    "version": "1",
    "environments": [
        {
            "name": "ssh-remote",
            "type": "ssh",
            "remoteUri": "ssh://user@hostname:22"
        }
    ]
}

Pré-requisitos para um ambiente remoto do Windows

Analise os pré-requisitos a seguir para um ambiente remoto do Windows.

Verifique se o Sistema de Arquivos Projetado do Windows está habilitado no computador remoto. Você pode executar o seguinte em uma janela do PowerShell de administrador para habilitá-lo:
```
 Enable-WindowsOptionalFeature -Online -FeatureName Client-ProjFS -NoRestart
```
Reinicie o ambiente conforme necessário.
Verifique se o SSH está configurado. Você pode examinar as etapas em Instalar o OpenSSH. Inicie o servidor SSH executando o seguinte comando em uma janela de administrador do PowerShell:
```
Start-Service sshd
```
Verifique se o runtime apropriado do .NET exigido pelos testes está instalado. Você pode baixar o .NET para Windows.
Prepare o ambiente para testes de depuração:
1. Instale o SKU de ferramentas remotas no ambiente remoto.
2. Inicie o depurador remoto como administrador e verifique se o usuário do Visual Studio tem permissões para se conectar.

Pré-requisitos para um ambiente remoto do Linux

Examine os pré-requisitos a seguir para um ambiente remoto do Linux.

Verifique se o SSH está configurado e em execução.
Instale fuse3 usando um gerenciador de pacotes.
Verifique se o runtime apropriado do .NET exigido pelos testes está instalado no ambiente remoto do Linux.

Usar o Gerenciador de Testes para executar e depurar testes remotos

Veja como você pode usar o Gerenciador de Testes para executar e depurar seus testes de ambiente remoto.

O ambiente ativo é selecionado por meio de uma lista suspensa na barra de ferramentas do Gerenciador de Testes. Atualmente, apenas um ambiente de teste pode estar ativo por vez.
Depois que um ambiente é selecionado, os testes são descobertos e executados no novo ambiente.
Agora você pode executar seus testes dentro do remoto e depurar seus testes em ambientes!
O Gerenciador de Testes pode solicitar que você instale alguns pré-requisitos de ambiente ausentes e tente instalar dependências ausentes. Atualmente, a maior parte do provisionamento do ambiente é deixada para a especificação do usuário.

Compartilhar via

Teste remoto (versão prévia experimental)

Requisitos

Configurar o ambiente de teste remoto

Propriedades de um ambiente em testenvironments.json

Conexões de contêiner local

Conexões WSL2 locais

Conexões SSH

Pré-requisitos para um ambiente remoto do Windows

Pré-requisitos para um ambiente remoto do Linux

Usar o Gerenciador de Testes para executar e depurar testes remotos

Comentários

Recursos adicionais

Compartilhar via

Teste remoto (versão prévia experimental)

Requisitos

Configurar o ambiente de teste remoto

Propriedades de um ambiente em testenvironments.json

Conexões de contêiner local

Conexões WSL2 locais

Conexões SSH

Pré-requisitos para um ambiente remoto do Windows

Pré-requisitos para um ambiente remoto do Linux

Usar o Gerenciador de Testes para executar e depurar testes remotos

Conteúdo relacionado

Comentários

Recursos adicionais