Remotetests (experimentelle Vorschau)

  • Artikel

Remotetests ermöglichen es Entwicklern, Visual Studio 2022 mit Remoteumgebungen zum Ausführen und Debuggen von Tests zu verbinden. Diese Funktionalität ist nützlich für plattformübergreifend arbeitende Entwickler, die Code für mehrere verschiedene Zielumgebungen bereitstellen, z. B. für Windows oder das Linux-Betriebssystem. Normalerweise pushen Entwickler*innen z. B. Änderungen in eine CI-Pipeline, um Feedback von einem Test zu erhalten, der unter Linux ausgeführt wird. Mit diesem Remotetestfeature können Sie Linux-Tests direkt in Visual Studio ausführen, indem Sie den Test-Explorer mit einer Remoteumgebung verbinden.

Anforderungen

Die folgenden Anforderungen gelten für die experimentelle Version von Remotetests:

  • Sie müssen Visual Studio 2022 Update 17.0 Preview 3 oder höher ausführen.

  • Derzeit unterstützt die Funktion nur .NET- und .NET Framework-Tests.

  • Derzeit unterstützt das Feature nur Windows-, Ubuntu- und Debian-Images in der Remoteumgebung. Für .NET Framework werden nur entfernte Windows-Umgebungen unterstützt.

  • Gegenwärtig obliegt der größte Teil der Umgebungsbereitstellung den Angaben der Benutzer*innen.

    Die Benutzer*innen müssen die erforderlichen Abhängigkeiten in der Zielumgebung installieren. Wenn Ihre Tests beispielsweise .NET 6.0 betreffen, müssen Sie über Ihr Dockerfile sicherstellen, dass .NET 6.0 im Container installiert ist. Möglicherweise wird eine Aufforderung zum Installieren von .NET Core in der Remoteumgebung angezeigt, da dies zur Remoteausführung und -erkennung von Tests erforderlich ist.

  • Planen Sie die Überwachung des Verbindungsstatus mit der Remoteumgebung über den Bereich Ausgabe>Tests.

    Wenn z. B. der Container beendet wird, wird eine Meldung im Bereich Ausgabe>Tests angezeigt. Möglicherweise erfasst das Feature nicht alle Szenarien. Planen Sie daher eine Überprüfung Ihrer Ausgabe ein, um festzustellen, ob die Verbindung getrennt wurde. Insbesondere wenn der Bereich Ausgabe nicht auf „Test“ festgelegt ist, wird die Meldung möglicherweise nicht sofort angezeigt. Wenn die Verbindung getrennt worden ist, können Sie die Verbindung über die Dropdownliste für Remotetestumgebungen im Test-Explorer wieder auf Ihre lokale Umgebung zurücksetzen und dann erneut die Remoteumgebung auswählen, um die Verbindung wiederherzustellen.

Einrichten der Remotetestumgebung

Umgebungen werden mithilfe der Datei testvironments.json im Stammverzeichnis Ihrer Lösung angegeben. Die JSON-Dateistruktur implementiert das folgende Schema:

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

Eigenschaften einer Umgebung in „testenvironments.json“

Die Datei testenvironments.json verfügt über die folgenden Umgebungseigenschaften.

Eigenschaft Typ Beschreibung
name string Benutzerfreundlicher Umgebungsname, der im Test-Explorer angezeigt wird. Der Wert muss innerhalb einer testEnvironments.json-Datei eindeutig sein.
localRoot Zeichenfolge [Optional] Pfad auf dem lokalen Computer (entweder absolut oder relativ zum Projektmappenverzeichnis), der in die Remoteumgebung projiziert wird. Wenn keine Angabe erfolgt, wird als Standardwert der Repositorystamm im Kontext eines Git-Repositorys verwendet (ab Visual Studio 2022 Version 17.1). Außerhalb eines Git-Repositorys wird als Standardwert das Lösungsverzeichnis verwendet.
type enum Gibt den Typ der Remoteumgebung an. Der Wert kann entweder docker, wsl oder ssh lauten.
dockerImage Zeichenfolge Name eines Docker-Images, das in einer Docker-Umgebung geladen werden soll.
Dieser Wert ist erforderlich, wenn die Umgebung type docker ist.
dockerFile Zeichenfolge Pfad zu einer Docker-Datei relativ zum Projektmappenverzeichnis, um ein Image zu erstellen und in einer Docker-Umgebung zu laden.
Dieser Wert ist erforderlich, wenn die Umgebung type docker ist.
wslDistribution Zeichenfolge Name der lokalen WSL-Verteilung, in der die Testumgebung ausgeführt werden soll.
Dieser Wert ist erforderlich, wenn die Umgebung type wsl ist.
remoteUri Zeichenfolge Ein URI, der die Verbindung mit dem Remotecomputer angibt. Beispiel: ssh://user@hostname:22.
Dieser Wert ist erforderlich, wenn die Umgebung type ssh ist.

Hinweis

Sie müssen entweder die Eigenschaft dockerImage oder die Eigenschaft dockerFile angeben, aber nicht beide Eigenschaften.

Lokale Containerverbindungen

Um eine Verbindung mit einem lokal ausgeführten Container herzustellen, muss Docker Desktop auf Ihrem lokalen Computer installiert sein. Aktivieren Sie optional die WSL2-Integration, um eine bessere Leistung zu erzielen.

Für ein Dockerfile-Datei kann die Umgebung in der Datei testEnvironments.json im Stammverzeichnis Ihrer Projektmappe angegeben werden: Es verfügt über folgende Eigenschaften:

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

Das folgende Beispiel zeigt die Datei testenvironments.json für ein lokales Containerimage namens <mcr.microsoft.com/dotnet/sdk>.

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

Das folgende Beispiel zeigt ein Dockerfile zum Ausführen von Tests für .NET 5.0. Die zweite Zeile stellt sicher, dass der Debugger eine Verbindung herstellen und in Ihrem Container ausführen kann.

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

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

Der Container muss über ein integriertes Image auf Ihrem lokalen Computer verfügen. Sie können einen Container mit dem Befehl docker build -t <docker image name> -f <path to Dockerfile> . erstellen. Vergessen Sie nicht den Punkt . am Ende des Befehls.

Im folgenden Beispiel wird die dockerFile-Eigenschaft anstelle der dockerImage-Eigenschaft verwendet.

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

Lokale WSL2-Verbindungen

Zum Remotestart von Tests auf WSL2 müssen Sie auf Ihrem lokalen Computer die WSL2-Integration aktivieren.

Für ein Dockerfile-Datei kann die Umgebung in der Datei testEnvironments.json im Stammverzeichnis Ihrer Projektmappe nach dem folgenden Schema angegeben werden. Ersetzen Sie den Wert <Ubuntu> der wslDistribution-Eigenschaft durch die Installation der WSL2-Distribution.

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

SSH-Verbindungen

Wechseln Sie zu Extras > Optionen > Plattformübergreifend > Verbindungs-Manager, um SSH-Verbindungen hinzuzufügen oder zu entfernen. Wählen Sie Hinzufügen aus, um den Hostnamen, den Port und erforderliche Anmeldeinformationen einzugeben.

Für ein Dockerfile-Datei kann die Umgebung in der Datei testEnvironments.json im Stammverzeichnis Ihrer Projektmappe nach dem folgenden Schema angegeben werden. Ersetzen Sie den Wert <ssh://user@hostname:22> der remoteUri-Eigenschaft durch Ihren SSH-Wert.

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

Voraussetzungen für eine Windows-Remoteumgebung

Überprüfen Sie die folgenden Voraussetzungen für eine Windows-Remoteumgebung.

  1. Stellen Sie sicher, dass Windows Projected File System auf dem entfernten Rechner aktiviert ist. Führen Sie in einem PowerShell-Fenster als Administrator folgenden Code aus, um diese Option zu aktivieren:

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

    Starten Sie die Umgebung nach Bedarf neu.

  2. Vergewissern Sie sich, dass SSH eingerichtet ist. Die entsprechenden Schritte finden Sie unter Installieren von OpenSSH. Starten Sie den SSH-Server, indem Sie in einem PowerShell-Fenster als Administrator den folgenden Befehl ausführen:

    Start-Service sshd

  3. Stellen Sie sicher, dass die für Ihre Tests erforderliche .NET-Runtime installiert ist. Sie können .NET für Windows herunterladen.

  4. Bereiten Sie die Umgebung für Debuggingtests vor:

    1. Installieren Sie die SKU für Remotetools in der Remoteumgebung.

    2. Starten Sie den Remotedebugger als Administrator, und stellen Sie sicher, dass die Visual Studio-Benutzer*innen über Berechtigungen zum Herstellen einer Verbindung verfügt.

Voraussetzungen für eine Linux-Remoteumgebung

Überprüfen Sie die folgenden Voraussetzungen für eine Linux-Remoteumgebung.

  1. Stellen Sie sicher, dass ssh konfiguriert ist und ausgeführt wird.

  2. Installieren Sie fuse3 mit einem Paket-Manager.

  3. Stellen Sie sicher, dass die für Ihre Tests erforderliche .NET-Runtime in der Linux-Remoteumgebung installiert ist.

Verwenden des Test-Explorers zum Ausführen und Debuggen von Remotetests

Hier erfahren Sie, wie Sie den Test-Explorer verwenden können, um die Remoteumgebungstests auszuführen und zu debuggen.

  • Die aktive Umgebung wird über eine Dropdownliste in der Symbolleiste des Test-Explorers ausgewählt. Derzeit kann immer nur eine Testumgebung aktiv sein.

    Dropdownliste für Remotetestumgebungen im Test-Explorer

  • Nachdem Sie eine Umgebung ausgewählt haben, werden Tests in der neuen Umgebung ermittelt und ausgeführt.

    Tests werden in Remoteumgebungen ermittelt und ausgeführt

  • Sie können Ihre Tests jetzt im Remotemodus ausführen und in Umgebungen debuggen.

    Anzeigen von Testergebnissen aus der Remoteumgebung im Test-Explorer

  • Test-Explorer fordert Sie möglicherweise auf, einige fehlende Umgebungsvoraussetzungen zu installieren, und versucht, fehlende Abhängigkeiten zu installieren. Der Großteil der Bereitstellung der Remoteumgebung obliegt jedoch den Spezifikationen der Benutzer*innen.

Zugehöriger Inhalt