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 , wsl lub 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/sdk>
.
{
"version": "1",
"environments": [
{
"name": "linux dotnet-sdk-5.0",
"type": "docker",
"dockerImage": "mcr.microsoft.com/dotnet/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/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
Połączenia SSH można dodawać lub usuwać w obszarze Narzędzia > Opcje > międzyplatformowe > Menedżer połączeń. 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.
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.
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
Upewnij się, że zainstalowano odpowiednie środowisko uruchomieniowe platformy .NET wymagane przez testy. Możesz pobrać platformę .NET dla systemu Windows.
Przygotuj środowisko do debugowania testów:
Zainstaluj jednostkę SKU narzędzi zdalnych w środowisku zdalnym.
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.
Upewnij się, że protokół SSH jest skonfigurowany i uruchomiony.
Zainstaluj
fuse3
za pomocą menedżera pakietów.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.