Testowanie zdalne (wersja zapoznawcza eksperymentalna)

Testowanie zdalne umożliwia deweloperom łączenie programu Visual Studio 2022 ze środowiskami zdalnymi na potrzeby uruchamiania i debugowania testów. Ta funkcja jest przydatna dla deweloperów międzyplatformowych, którzy wdrażają kod w wielu różnych środowiskach docelowych, takich jak różne systemy operacyjne Windows lub Linux. Na przykład zwykle deweloper wypycha zmiany do potoku ciągłej integracji, aby uzyskać opinie z testu uruchomionego w systemie Linux. Funkcja testowania zdalnego umożliwia uruchamianie testów systemu Linux bezpośrednio z poziomu programu Visual Studio przez połączenie Eksploratora testów ze środowiskiem zdalnym.

Wymagania

Następujące wymagania dotyczą eksperymentalnej wersji testowania zdalnego:

• Musisz uruchomić program Visual Studio 2022 Update 17.0 (wersja zapoznawcza 3 lub nowsza).

• Obecnie funkcja obsługuje tylko testy platform .NET i .NET Framework.

  • Jeśli interesuje Cię obsługa testowania zdalnego dla innych języków, możesz zgłosić sugestię lub wywołać istniejącą sugestię. Obsługa testowania zdalnego języka C++.

• Obecnie funkcja obsługuje obrazy systemów Windows, Ubuntu i Debian w środowisku zdalnym. W przypadku programu .NET Framework obsługiwane są tylko zdalne środowiska systemu Windows.

• Obecnie większość aprowizacji środowiska pozostaje w specyfikacji użytkownika.

  Użytkownik musi zainstalować niezbędne zależności w środowisku docelowym. Jeśli na przykład testy są przeznaczone dla platformy .NET 6.0, upewnij się, że kontener ma zainstalowany program .NET 6.0 za pośrednictwem pliku Dockerfile. Może pojawić się monit o zainstalowanie platformy .NET Core w środowisku zdalnym, który jest wymagany do zdalnego uruchamiania i odnajdywania testów.

• Zaplanuj monitorowanie stanu połączenia ze środowiskiem zdalnym przy użyciu okienka Testy wyjściowe>.

  Jeśli na przykład kontener zostanie zatrzymany, w okienku Testy wyjściowe>pojawi się komunikat. Funkcja może nie wykryć wszystkich scenariuszy, dlatego zaplanuj sprawdzenie danych wyjściowych, jeśli wygląda na to, że połączenie zostanie utracone. W szczególności jeśli okienko Dane wyjściowe nie jest ustawione na "Test", może nie zostać natychmiast wyświetlony komunikat. Jeśli połączenie zostanie utracone, możesz użyć listy rozwijanej środowiska w Eksploratorze testów, aby ustawić połączenie z powrotem do środowiska lokalnego, a następnie ponownie wybrać środowisko zdalne, aby ponownie nawiązać połączenie.

Konfigurowanie środowiska testowania zdalnego

Środowiska są określane przy użyciu pliku testenvironments.json w katalogu głównym rozwiązania. Struktura plików JSON implementuje następujący schemat:

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

Właściwości środowiska w testenvironments.json

Plik testenvironments.json ma następujące właściwości środowiska.

Właściwość	Type	opis
name	string	Przyjazna dla użytkownika nazwa środowiska wyświetlana w Eksploratorze testów. Musi być unikatowy w pliku testEnvironments.json .
localRoot	string	[Opcjonalnie] Ścieżka na komputerze lokalnym (bezwzględnym lub względnym względem katalogu rozwiązania), który jest przewidywany w środowisku zdalnym. Jeśli nie zostanie określony, wartość domyślna to katalog główny repozytorium w kontekście repozytorium Git (w programie Visual Studio 2022 w wersji 17.1 lub nowszej). Poza repozytorium git domyślną wartością jest katalog rozwiązania.
type	wyliczenie	Wskazuje typ środowiska zdalnego. Wartość może mieć wartość docker, wsllub ssh.
dockerImage	string	Nazwa obrazu platformy Docker do załadowania w środowisku platformy Docker. Ta wartość jest wymagana, jeśli środowisko type ma wartość docker.
dockerFile	string	Ścieżka do pliku platformy Docker względem katalogu rozwiązania w celu skompilowania obrazu i załadowania go w środowisku platformy Docker. Ta wartość jest wymagana, jeśli środowisko type ma wartość docker.
wslDistribution	string	Nazwa lokalnej dystrybucji WSL, w której ma zostać uruchomione środowisko testowe. Ta wartość jest wymagana, jeśli środowisko type ma wartość wsl.
remoteUri	string	Identyfikator URI określający połączenie z maszyną zdalną. Na przykład ssh://user@hostname:22. Ta wartość jest wymagana, jeśli środowisko type ma wartość ssh.

Uwaga

Należy określić właściwość dockerImage lub dockerFile , ale nie obie właściwości.

Połączenia kontenerów lokalnych

Aby nawiązać połączenie z kontenerem uruchomionym lokalnie, musisz mieć program Docker Desktop na komputerze lokalnym. Opcjonalnie włącz integrację ZSL2, aby uzyskać lepszą wydajność.

W przypadku pliku Dockerfile środowisko można określić w pliku testEnvironments.json w katalogu głównym rozwiązania. Używa on następujących właściwości:

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

Poniższy przykład przedstawia plik testenvironments.json dla lokalnego obrazu kontenera o nazwie <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"
        }
    ]
}

Poniższy przykład przedstawia plik Dockerfile do uruchamiania testów przeznaczonych dla platformy .NET 5.0. Drugi wiersz zapewnia, że debuger może nawiązać połączenie i uruchomić go w kontenerze.

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

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

Kontener musi mieć utworzony obraz na maszynie lokalnej. Kontener można utworzyć za pomocą polecenia docker build -t <docker image name> -f <path to Dockerfile> . Pamiętaj, aby uwzględnić kropkę . na końcu polecenia.

W poniższym przykładzie pokazano użycie dockerFile właściwości zamiast dockerImage właściwości .

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

Lokalne połączenia WSL2

Aby zdalnie uruchamiać testy w systemie WSL2, należy włączyć integrację ZSL2 na komputerze lokalnym.

Środowisko można określić w pliku testEnvironments.json w katalogu głównym rozwiązania przy użyciu następującego schematu. Zastąp <Ubuntu> wartość wslDistribution właściwości instalacją dystrybucji WSL2.

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

Połączenia SSH

Możesz dodawać lub usuwać połączenia SSH w obszarze Narzędzia > Opcje > międzyplatformowe > Połączenie ion Manager. Wybierz pozycję Dodaj , aby wprowadzić nazwę hosta, port i wymagane poświadczenia.

Środowisko można określić w pliku testEnvironments.json w katalogu głównym rozwiązania przy użyciu następującego schematu. Zastąp <ssh://user@hostname:22> wartość remoteUri właściwości wartością SSH.

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

Wymagania wstępne dotyczące środowiska zdalnego systemu Windows

Zapoznaj się z poniższymi wymaganiami wstępnymi dotyczącymi zdalnego środowiska systemu Windows.

1. Upewnij się, że system plików projected systemu Windows jest włączony na maszynie zdalnej. Aby go włączyć, możesz uruchomić następujący kod w oknie administratora programu PowerShell:

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

   Uruchom ponownie środowisko zgodnie z potrzebami.

2. Upewnij się, że protokół SSH został skonfigurowany. Możesz przejrzeć kroki opisane w temacie Instalowanie protokołu OpenSSH. Uruchom serwer SSH, uruchamiając następujące polecenie w oknie administratora programu PowerShell:

   Start-Service sshd
   

3. Upewnij się, że zainstalowano odpowiednie środowisko uruchomieniowe platformy .NET wymagane przez testy. Możesz pobrać platformę .NET dla systemu Windows.

4. Przygotuj środowisko do debugowania testów:

   1. Zainstaluj jednostkę SKU narzędzi zdalnych w środowisku zdalnym.

   2. Uruchom zdalny debuger jako administrator i upewnij się, że użytkownik programu Visual Studio ma uprawnienia do nawiązywania połączenia.

Wymagania wstępne dotyczące zdalnego środowiska systemu Linux

Zapoznaj się z poniższymi wymaganiami wstępnymi dotyczącymi zdalnego środowiska systemu Linux.

1. Upewnij się, że protokół SSH jest skonfigurowany i uruchomiony.

2. Zainstaluj fuse3 za pomocą menedżera pakietów.

3. Upewnij się, że odpowiednie środowisko uruchomieniowe platformy .NET wymagane przez testy jest zainstalowane w zdalnym środowisku systemu Linux.

Uruchamianie i debugowanie testów zdalnych za pomocą Eksploratora testów

Poniżej przedstawiono sposób uruchamiania i debugowania zdalnych testów za pomocą Eksploratora testów.

• Aktywne środowisko jest wybierane za pośrednictwem listy rozwijanej na pasku narzędzi Eksplorator testów. Obecnie tylko jedno środowisko testowe może być aktywne naraz.

  

• Po wybraniu środowiska testy zostaną odnalezione i uruchomione w nowym środowisku.

  

• Teraz możesz uruchamiać testy w środowisku zdalnym i debugować testy w środowiskach.

  

• Eksplorator testów może monitować o zainstalowanie niektórych brakujących wymagań wstępnych środowiska i podjęcie próby zainstalowania brakujących zależności. Jednak większość aprowizacji środowiska zdalnego jest do specyfikacji użytkownika.

Powiązana zawartość

• Debugowanie testów jednostkowych za pomocą Eksploratora testów
• Uruchamianie testu jednostkowego jako procesu 64-bitowego
• Eksplorator testów — często zadawane pytania