Komponententest

Artikel
06/08/2024

Plattformübergreifende Apps sollten so getestet werden, wie sie in der realen Welt verwendet werden, um ihre Qualität, Zuverlässigkeit und Leistung zu verbessern. Viele Arten von Tests sollten für eine App durchgeführt werden, einschließlich Komponententests, Integrationstests und Benutzeroberflächentests. Komponententests sind die am häufigsten verwendete Form. Sie sind für die Erstellung qualitativ hochwertiger Apps unerlässlich.

Ein Komponententest verwendet eine kleine Einheit einer App, in der Regel eine Methode, isoliert sie vom Rest des Codes und überprüft, ob sie sich wie erwartet verhält. Ziel ist es, zu überprüfen, ob jede Funktionseinheit wie erwartet ausgeführt wird, sodass Fehler nicht in der gesamten App auftreten. Es ist effizienter, einen Fehler genau dort zu erkennen, wo er auftritt, anstatt die Auswirkung des Fehlers indirekt an einer sekundären Fehlerstelle zu beobachten.

Komponententests sollten in der Regel das Muster „anordnen, agieren, attestieren“ verwenden (Engl. arrange, act, assert):

Schritt	BESCHREIBUNG
Anordnen	Initialisieren Sie Objekte, und legen Sie den Wert der Daten fest, die an die zu testende Methode übergeben werden.
Agieren	Rufen Sie die getestete Methode mit den erforderlichen Argumenten auf.
Assert	Attestieren (bestätigen) Sie, dass die Aktion der zu testenden Methode wie erwartet funktioniert.

Dieses Muster stellt sicher, dass Komponententests lesbar, selbstbeschreibend und konsistent sind.

Komponententests wirken sich am stärksten auf die Codequalität aus, wenn sie ein integraler Bestandteil des Workflows bei der Softwareentwicklung sind. Komponententests können als Entwurfsdokumentation und funktionale Spezifikationen für Ihre App fungieren. Sobald eine Methode geschrieben wurde, sollten Komponententests geschrieben werden, die das Verhalten der Methode als Reaktion auf Standard-, Begrenzungs- und falsche Eingabedatenfälle überprüfen und explizite oder implizite Annahmen des Codes überprüfen. Alternativ werden Komponententests mit testgesteuerter Entwicklung vor dem Code geschrieben.

Wichtig

Komponententests sind sehr effektiv gegen Regression. Damit sind Funktionen gemeint, die funktioniert haben, aber durch ein fehlerhaftes Update gestört wurden.

xUnit ist das empfohlene Testframework für .NET MAUI-Apps.

Hinzufügen von xUnit-Tests zu einer .NET MAUI-Lösung

Verwenden Sie eine der folgenden Vorgehensweisen, um Ihrer .NET MAUI-Lösung xUnit-Tests hinzuzufügen:

Verwenden Sie Visual Studio, um Ihrer Lösung ein neues xUnit-Testprojekt hinzuzufügen.

ODER
Verwenden Sie die .NET-CLI, um ein neues xUnit-Testprojekt zu erstellen und es Ihrer Lösung hinzuzufügen. Weitere Informationen finden Sie unter Komponententests für C# in .NET mithilfe von „dotnet test“ und xUnit.

Die Projektdatei (.csproj) für das xUnit-Testprojekt ähnelt dem folgenden Beispiel:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>

    <IsPackable>false</IsPackable>
    <IsTestProject>true</IsTestProject>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="coverlet.collector" Version="6.0.0" />
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.8.0" />
    <PackageReference Include="xunit" Version="2.5.3" />
    <PackageReference Include="xunit.runner.visualstudio" Version="2.5.3" />
  </ItemGroup>

  <ItemGroup>
    <Using Include="Xunit" />
  </ItemGroup>

</Project>

Die Buildeigenschaft $(TargetFramework) gibt das Zielframework für das Testprojekt an. Dies ist die neueste Version von .NET, die auf Ihrem Computer installiert ist.

Das xunit-Paket enthält untergeordnete Pakete, die das Testframework selbst sowie Roslyn-Analysemodule enthalten, die häufige Probleme bei Komponententests erkennen. Die Pakete xunit.runner.visualstudio und Microsoft.NET.Test.Sdk sind erforderlich, um die Komponententests in Visual Studio und mit dem Befehl dotnet test auszuführen. Das coverlet.collector-Paket ermöglicht das Sammeln von Code Coverage. Wenn Sie nicht beabsichtigen, Code Coverage zu sammeln, können Sie diesen Paketverweis entfernen. Weitere Informationen zu Code Coverage für Komponententests finden Sie unter Verwenden von Code Coverage für Komponententests.

Es gibt zwei Hauptansätze für die Strukturierung Ihrer App für Komponententests:

Der Code, den Sie einem Komponententest unterziehen, befindet sich in einem .NET MAUI-Klassenbibliotheksprojekt.
Der Code, den Sie einem Komponententest unterziehen, befindet sich in einem .NET MAUI-App-Projekt.

Jeder Ansatz erfordert eine bestimmte Konfiguration.

Konfigurieren eines .NET MAUI-Klassenbibliotheksprojekts für Komponententests

Bei diesem Ansatz befindet sich der Code, den Sie einem Komponententest unterziehen möchten, in einem .NET MAUI-Klassenbibliotheksprojekt, das von Ihrem .NET MAUI-App-Projekt genutzt wird. Zum Schreiben von Komponententests für die .NET MAUI-Klassenbibliothek müssen Sie die vom Projekt verwendeten Zielframeworks aktualisieren. Dies können Sie erledigen, indem Sie den Wert der Buildeigenschaft $(TargetFramework) aus der xUnit-Testprojektdatei (.csproj) der Buildeigenschaft $(TargetFrameworks) in der .NET MAUI-Klassenbibliotheksprojektdatei hinzufügen:

<TargetFrameworks>net8.0;net8.0-android;net8.0-ios;net8.0-maccatalyst</TargetFrameworks>

In diesem Beispiel wurde der Buildeigenschaft $(TargetFrameworks) in der .NET MAUI-Klassenbibliotheksprojektdatei der Wert net8.0 hinzugefügt.

Anschließend müssen Sie einen Verweis auf Ihr .NET MAUI-Klassenbibliotheksprojekt von Ihrem xUnit-Testprojekt hinzufügen.

Konfigurieren eines .NET MAUI-App-Projekts für Komponententests

Bei diesem Ansatz befindet sich der Code, den Sie einem Komponententest unterziehen möchten, in einem .NET MAUI-App-Projekt. Zum Schreiben von Komponententests für das .NET MAUI-App-Projekt müssen Sie die vom Projekt verwendeten Zielframeworks aktualisieren. Dies können Sie erledigen, indem Sie den Wert der Buildeigenschaft $(TargetFramework) aus der xUnit-Testprojektdatei (.csproj) der Buildeigenschaft $(TargetFrameworks) in der .NET MAUI-App-Projektdatei hinzufügen:

<TargetFrameworks>net8.0;net8.0-android;net8.0-ios;net8.0-maccatalyst</TargetFrameworks>

In diesem Beispiel wurde der Buildeigenschaft $(TargetFrameworks) in der .NET MAUI-App-Projektdatei der Wert net8.0 hinzugefügt.

Sie müssen Ihr .NET MAUI-App-Projekt auch so ändern, dass keine ausführbare Datei für das Zielframework ausgegeben wird, das vom xUnit-Testprojekt verwendet wird. Dies kann durch Hinzufügen einer Bedingung zur Buildeigenschaft $(OutputType) in der .NET MAUI-App-Projektdatei erreicht werden:

<OutputType Condition="'$(TargetFramework)' != 'net8.0'">Exe</OutputType>

In diesem Beispiel erzeugt das .NET MAUI-App-Projekt nur eine ausführbare Datei, wenn das Zielframework nicht net8.0 ist.

Anschließend müssen Sie einen Verweis auf Ihr .NET MAUI-App-Projekt von Ihrem xUnit-Testprojekt hinzufügen.

Schreiben von Komponententests

xUnit unterstützt zwei verschiedene Typen von Komponententests:

Testtyp	attribute	BESCHREIBUNG
Fakten	`Fact`	Tests, die immer „true“ sind und die invariante Bedingungen testen.
Theorien	`Theory`	Tests, die nur für einen bestimmten Teil der Daten „true“ sind.

Komponententests sollten in Ihrem xUnit-Testprojekt platziert und mit dem Attribut [Fact] oder [Theory] versehen werden. Das folgende Beispiel zeigt Komponententests, die das Attribut [Fact] verwenden:

namespace MyUnitTests
{
    public class MyTests
    {
        [Fact]
        public void PassingTest()
        {
            Assert.AreEqual(4, 2+2);
        }

        [Fact]
        public void FailingTest()
        {
            Assert.AreEqual(5, 2+2);
        }
    }
}

In diesem Beispiel stellen die Tests einen absichtlich erfolgreichen und fehlerhaften Test dar.

Das folgende Beispiel zeigt Komponententests, die das Attribut [Theory] verwenden:

namespace MyUnitTests
{
    public class MyTests
    {
        [Theory]
        [InlineData(3)]
        [InlineData(4)]
        [InlineData(5)]
        public void MyTheoryTest(int value)
        {
            Assert.True(value % 2 == 1);
        }
    }
}

In diesem Beispiel gibt es zwar nur eine Testmethode, doch gibt es tatsächlich drei Tests, da die Theorie einmal für jedes Datenelement ausgeführt wird.

Tipp

Testen Sie einen Vorgang mit jedem Komponententest. Da die Komplexität eines Tests steigt, wird die Überprüfung dieses Tests erschwert. Indem Sie einen Komponententest auf ein einzelnes Problem beschränken, können Sie sicherstellen, dass Ihre Tests wiederholbar und isoliert sind und eine kürzere Ausführungszeit haben. Weitere Informationen finden Sie unter Bewährte Methoden für Komponententests.