Condividi tramite

Test remoto (anteprima sperimentale)

  • Articolo

Il test remoto consente agli sviluppatori di connettere Visual Studio 2022 agli ambienti remoti per l'esecuzione e il debug dei test. Questa funzionalità è utile per gli sviluppatori multipiattaforma che distribuiscono il codice in più ambienti di destinazione diversi, ad esempio sistemi operativi Windows o Linux diversi. Ad esempio, in genere uno sviluppatore esegue il push delle modifiche a una pipeline CI per ottenere feedback da un test in esecuzione in Linux. Con la funzionalità di test remoto, è possibile eseguire test Linux direttamente da Visual Studio connettendo Esplora test a un ambiente remoto.

Requisiti

I requisiti seguenti si applicano alla versione sperimentale dei test remoti:

  • È necessario eseguire Visual Studio 2022 Update 17.0 Preview 3 o versione successiva.

  • Attualmente, la funzionalità supporta solo test .NET e .NET Framework.

  • Attualmente, la funzionalità supporta immagini Windows, Ubuntu e Debian nell'ambiente remoto. Per .NET Framework sono supportati solo gli ambienti Windows remoti.

  • Attualmente, la maggior parte del provisioning dell'ambiente viene lasciata alla specifica dell'utente.

    L'utente deve installare le dipendenze necessarie nell'ambiente di destinazione. Ad esempio, se i test hanno come destinazione .NET 6.0, è necessario assicurarsi che il contenitore abbia .NET 6.0 installato tramite dockerfile. Potrebbe essere necessario un prompt per installare .NET Core nell'ambiente remoto, necessario per eseguire e individuare i test in remoto.

  • Pianificare il monitoraggio dello stato della connessione all'ambiente remoto usando il riquadro Test di output>.

    Ad esempio, se il contenitore si arresta, viene visualizzato un messaggio nel riquadro Test di output>. La funzionalità potrebbe non rilevare tutti gli scenari, quindi pianificare di controllare l'output se sembra che la connessione venga persa. In particolare, se il riquadro Output non è impostato su "Test", è possibile che il messaggio non venga visualizzato immediatamente. Se la connessione viene persa, è possibile usare l'elenco a discesa ambiente in Esplora test per ripristinare la connessione all'ambiente locale e quindi selezionare di nuovo l'ambiente remoto per riconnettersi.

Configurare l'ambiente di test remoto

Gli ambienti vengono specificati usando il file testenvironments.json nella radice della soluzione. La struttura di file JSON implementa lo schema seguente:

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

Proprietà di un ambiente in testenvironments.json

Il file testenvironments.json ha le proprietà di ambiente seguenti.

Proprietà Type Descrzione
name stringa Nome dell'ambiente descrittivo visualizzato in Esplora test. Deve essere univoco all'interno di un file di testEnvironments.json .
localRoot string [Facoltativo] Percorso nel computer locale (assoluto o relativo alla directory della soluzione), proiettato nell'ambiente remoto. Se non specificato, il valore predefinito è la radice del repository nel contesto di un repository Git (in Visual Studio 2022 versione 17.1 e successive). All'esterno di un repository Git, il valore predefinito è la directory della soluzione.
type enum Indica il tipo di ambiente remoto. Il valore può essere docker, wslo ssh.
dockerImage string Nome di un'immagine Docker da caricare in un ambiente Docker.
Questo valore è obbligatorio se l'ambiente type è docker.
dockerFile string Percorso di un file Docker, relativo alla directory della soluzione, per compilare un'immagine e caricarla in un ambiente Docker.
Questo valore è obbligatorio se l'ambiente type è docker.
wslDistribution string Nome della distribuzione WSL locale in cui eseguire l'ambiente di test.
Questo valore è obbligatorio se l'ambiente type è wsl.
remoteUri string URI che specifica la connessione al computer remoto. Ad esempio: ssh://user@hostname:22.
Questo valore è obbligatorio se l'ambiente type è ssh.

Nota

È necessario specificare la dockerImage proprietà o dockerFile , ma non entrambe le proprietà.

Connessioni al contenitore locale

Per connettersi a un contenitore in esecuzione in locale, è necessario disporre di Docker Desktop nel computer locale. Facoltativamente, abilitare l'integrazione WSL2 per ottenere prestazioni migliori.

Per un Dockerfile, l'ambiente può essere specificato nel file testEnvironments.json nella radice della soluzione. Usa le proprietà seguenti:

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

Nell'esempio seguente viene illustrato il file testenvironments.json per un'immagine del contenitore locale denominata <mcr.microsoft.com/dotnet/sdk>.

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

L'esempio seguente illustra un Dockerfile per l'esecuzione di test destinati a .NET 5.0. La seconda riga assicura che il debugger possa connettersi ed eseguire nel contenitore.

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

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

Il contenitore deve avere un'immagine compilata nel computer locale. È possibile compilare un contenitore con il comando docker build -t <docker image name> -f <path to Dockerfile> . Assicurarsi di includere il punto . alla fine del comando.

Nell'esempio seguente viene illustrato l'utilizzo della dockerFile proprietà anziché della dockerImage proprietà .

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

Connessioni WSL2 locali

Per eseguire i test in remoto in WSL2, è necessario abilitare l'integrazione WSL2 nel computer locale.

L'ambiente può essere specificato nel file testEnvironments.json nella radice della soluzione usando lo schema seguente. Sostituire il <Ubuntu> valore della wslDistribution proprietà con l'installazione di WSL2 Distribution.

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

Connessioni SSH

È possibile aggiungere o rimuovere connessioni SSH in Strumenti > Opzioni > multipiattaforma > Gestione connessioni. Selezionare Aggiungi per immettere il nome host, la porta e le credenziali necessarie.

L'ambiente può essere specificato nel file testEnvironments.json nella radice della soluzione usando lo schema seguente. Sostituire il <ssh://user@hostname:22> valore della remoteUri proprietà con il valore SSH.

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

Prerequisiti per un ambiente Windows remoto

Esaminare i prerequisiti seguenti per un ambiente Windows remoto.

  1. Verificare che il file system proiettato di Windows sia abilitato nel computer remoto. È possibile eseguire il codice seguente da una finestra di PowerShell amministratore per abilitarla:

     Enable-WindowsOptionalFeature -Online -FeatureName Client-ProjFS -NoRestart

    Riavviare l'ambiente in base alle esigenze.

  2. Assicurarsi che SSH sia configurato. È possibile esaminare i passaggi descritti in Installare OpenSSH. Avviare il server SSH eseguendo il comando seguente da una finestra di PowerShell amministratore:

    Start-Service sshd

  3. Verificare che sia installato il runtime .NET appropriato richiesto dai test. È possibile scaricare .NET per Windows.

  4. Preparare l'ambiente per il debug dei test:

    1. Installare lo SKU Strumenti remoti nell'ambiente remoto.

    2. Avviare il debugger remoto come amministratore e assicurarsi che l'utente di Visual Studio disponga delle autorizzazioni per la connessione.

Prerequisiti per un ambiente Linux remoto

Esaminare i prerequisiti seguenti per un ambiente Linux remoto.

  1. Verificare che ssh sia configurato e in esecuzione.

  2. Eseguire l'installazione fuse3 usando una gestione pacchetti.

  3. Verificare che il runtime .NET appropriato richiesto dai test sia installato nell'ambiente Linux remoto.

Usare Esplora test per eseguire ed eseguire il debug di test remoti

Ecco come usare Esplora test per eseguire ed eseguire il debug dei test dell'ambiente remoto.

  • L'ambiente attivo viene selezionato tramite un elenco a discesa nella barra degli strumenti esplora test. Attualmente, un solo ambiente di test può essere attivo alla volta.

    Elenco a discesa Ambiente di test remoto in Esplora test

  • Dopo aver selezionato un ambiente, i test vengono individuati ed eseguiti nel nuovo ambiente.

    I test vengono individuati ed eseguiti in ambienti remoti

  • È ora possibile eseguire i test all'interno dell'ambiente remoto ed eseguire il debug dei test in ambienti.

    Visualizzare i risultati dei test dall'ambiente remoto in Esplora test

  • Esplora test può richiedere di installare alcuni prerequisiti di ambiente mancanti e tentare di installare dipendenze mancanti. Tuttavia, la maggior parte del provisioning dell'ambiente remoto è fino alla specifica dell'utente.

Contenuto correlato