Im vorherigen Artikel wurde das Blazor-Framework vorgestellt, mit dem mit C# Web-UIs erstellt werden können. In diesem zweiten Artikel wollen wir uns eine Test-Bibliothek ansehen, die in den Top10 der NuGet-Downloads für Blazor rangiert [1].
bUnit ist eine Bibliothek, mit der Unit Tests für Blazor-Komponenten erstellt werden. Sie ist seit 2021 als stabile Version verfügbar [2] und wird in der offiziellen Blazor-Dokumentation für Komponententests empfohlen [3].
Die Dokumentation für bUnit findet sich unter https://bunit.dev/
Razor-Syntax für eine Web-UI mit C# statt JavaScript
Alle Bausteine einer Blazor-App sind Razor-Komponenten mit der Dateiendung .razor. Darin wird die Website oder ein Teil davon in der sogenannten Razor-Syntax beschrieben. Das ist ein Mix aus HTML, speziellem Razor-Markup und C#. CSS wird zum Stylen verwendet.
Die klassische Blazor-Demo-Seite mit einem Zähler sieht so aus:
@page "/counter"
<PageTitle>Counter</PageTitle>
<h1>Counter</h1>
<p role="status">Current count: @currentCount</p>
<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>
@code {
private int currentCount = 0;
private void IncrementCount()
{
currentCount++;
}
}
Abbildung 1: Seite Counter.razor
In diesem Beispiel ist HTML und C# in einer Datei enthalten. Für komplexere Komponenten ist es hilfreich, beides voneinander zu trennen, indem eine code-behind-Datei angelegt wird. Die Datei für unsere Komponente Counter.razor heißt dann Counter.razor.cs. Der Compiler verknüpft die beiden Dateien automatisch miteinander, sodass uns IntelliSense beim Programmieren auf die Sprünge hilft.
Um die Code-Ausschnitte in diesem Artikel kürzer zu halten, wurde für alle Beispiele Markup und C# mit einer code-behind-Datei getrennt.
Komponenten in Blazor: Razor Components
Um Elemente zu kapseln und wiederverwendbar zu machen, realisiert man Funktionalitäten in Komponenten. Diese enthalten nur das Markup und den Code für eine einzelne Funktionalität. In der Website werden dann nur Komponenten eingefügt und eventuell Parameter und Callbacks angebunden. Komponenten können in eine Library verschoben und als NuGet-Pakete bereitgestellt werden.
Das Beispiel zeigt den gleichen Counter, nachdem er in einer Komponente CounterComponent.razor gekapselt wurde. Das visuelle Ergebnis im Browser ist gleich.
@page "/counter" @using BlazorWasmTemplateApp.Components <PageTitle>Counter</PageTitle> <h1>CounterComponent</h1> <CounterComponent/>
Abbildung 2: Seite Counter.razor mit Komponente
<p id="currentCount" role="status">Current count: @currentCount</p> <button id="incrementCountButton" class="btn btn-primary" @onclick="IncrementCount">Click me</button>
Abbildung 3: Markup für Counter-Komponente CounterComponent.razor
using Microsoft.AspNetCore.Components;
namespace BlazorWasmTemplateApp.Components
{
public partial class CounterComponent : ComponentBase
{
private int currentCount = 0;
private void IncrementCount()
{
currentCount++;
}
}
}
Abbildung 4: Code für Counter-Komponente CounterComponent.razor.cs
Unit Tests für die UI
Üblicherweise wird die UI einer Anwendung mit Ende-zu-Ende-Tests (E2E) überprüft. In der Web-Entwicklung kommen dafür Frameworks wie Selenium oder Playwright zum Einsatz. Diese Tests starten die gesamte Anwendung, rendern sie in einem Browser und führen dann die Testschritte durch. In solchen Tests wird eine Funktionalität oft durch die gesamte Anwendung hindurch getestet. Aufgrund der Komplexität sind E2E-Tests oft wartungsintensiv und langsam. Daher ist die allgemein anerkannte Empfehlung, nur einige wenige E2E-Tests und viele Komponententests zu schreiben (Testpyramide, siehe [4]).
Wenn man die UI testgetrieben nach den Prinzipien von Test Driven Development (TDD) entwickelt oder eine Benutzeroberfläche mit umfangreicher Logik programmiert, benötigt man viele Tests, die in kurzer Zeit ausgeführt werden. Daher hat es in solchen Fällen Nachteile, wenn man ausschließlich auf E2E-Tests setzt. bUnit-Tests sind das Gegenteil zu E2E-Tests, sie sind übersichtlich, isoliert voneinander und vor allem schnell. Ein Test benötigt oft nur einige Millisekunden für die Ausführung und fühlt sich an wie ein Unit Test im Backend.
bUnit ist auch eine gute Wahl, wenn man eine Bibliothek von Razor-Komponenten aufbaut. Nicht umsonst finden sich unter den Hauptsponsoren von bUnit Firmen wie Progress Telerik und Syncfusion, die u.a. Bibliotheken von Blazor-UI-Komponenten vertreiben.
Unit Tests für die UI mit bUnit sind also eine gute Ergänzung zu E2E-Tests, um Details der UI zu testen.
Erste Schritte mit bUnit
Vorbereitungen
bUnit ist kein Framework, sondern auf die Test Runner xUnit, NUnit oder MSTest angewiesen. Für die Beispiele in diesem Artikel wird xUnit verwendet. Die Ausführung der Tests erfolgt wie gewohnt über die IDE oder über die Kommandozeile mit dotnet test.
Da wir mit bUnit Razor-Komponenten testen wollen, müssen wir das SDK in der Projektdatei unseres Testprojekts auf Microsoft.NET.Sdk.Razor ändern. Details dazu finden sich in der bUnit-Dokumentation unter [5].
bUnit ist mit Test-Projekten in der Version .NET Standard 2.1 und mit allen .NET Core-Versionen ab 3.1 kompatibel.
Tests können in reinem C# oder in Razor-Syntax programmiert werden. Aus Gründen der Verständlichkeit wird ausschließlich die Variante mit C#-Code gezeigt. Mit Razor-Syntax ist es etwas einfacher, Parameter und Callbacks zu übergeben und HTML direkt mit einem erwarteten Markup zu vergleichen. Da ein Vergleich von HTML aber zu schlecht wartbaren Tests führt, ist dieser Vorteil der Razor-Syntax in der Praxis unwichtig.
Der erste Test
Wie könnte ein Test unserer CounterComponent aussehen? Wir wollen überprüfen, ob unser Zähler im Ausgangszustand 0 und nach einem Klick 1 anzeigt.
using Bunit;
namespace Tests
{
public class CounterComponentTests : TestContext
{
[Fact]
public void CurrentCount_IsZero_ByDefault()
{
//Arrange
var componentUnderTest = RenderComponent<CounterComponent>();
//Act
AngleSharp.Dom.IElement paragraph = componentUnderTest.Find("#currentCount");
//Assert
Assert.Equal("Current count: 0", paragraph.InnerHtml);
}
[Fact]
public void CurrentCount_Increases_WhenButtonClicked()
{
//Arrange
var componentUnderTest = RenderComponent<CounterComponent>();
AngleSharp.Dom.IElement button = componentUnderTest.Find("#incrementCountButton");
//Act
button.Click();
//Assert
AngleSharp.Dom.IElement paragraph = componentUnderTest.Find("#currentCount");
Assert.Equal("Current count: 1", paragraph.InnerHtml);
}
}
}
Abbildung 5: Einfacher Test der CounterComponent
Die generische Methode RenderComponent<TComponent>() mit TComponent als Typ der zu testenden Komponente erstellt ein Rendering. Dieses Rendering unserer CounterComponent mit seinen Attributen, Methoden und Eigenschaften entspricht der Darstellung der Komponente in einem Browser.
Um Interaktionen durchzuführen und den Inhalt des Renderings zu überprüfen, können wir Elemente mit der Methode Find() identifizieren. Diese Methode erwartet einen CSS-Selektor vom Typ string als Parameter. Ein CSS-Selektor ist ein Filter für die Elemente in einem HTML-DOM, der nach CSS-Klassen, Attributen, IDs oder HTML-Element-Typen filtern kann. Eine gute Referenz für CSS-Selektoren findet sich unter [6].
Der CSS-Selektor ‚#‘ filtert nach der ID des Elements. Der Selektor #currentCount filtert also das Element mit id=“currentCount“ heraus, das in unserer Beispielkomponente den aktuellen Wert des Zählers enthält.
Um zu ermitteln, ob unser Test erfolgreich ist, vergleichen wir den HTML-Inhalt mit einem erwarteten Text. Solche Tests sind fragil und wartungsintensiv, aber ein gutes Demo-Beispiel.
Komponenten mit Parametern testen
Wie sieht ein Test für eine Komponente mit Parametern aus? Dazu erweitern wir unsere CounterComponent um einen Parameter, mit dem wir den Startwert setzen können. Da wir unsere Komponente testgetrieben entwickeln wollen, fügen wir als erstes einen neuen Test hinzu. Darin nutzen wir eine Überladung der Methode RenderComponent() mit der man per Lambda-Ausdruck Parameter an einen ParameterBuilder übergibt.
Da wir testgetrieben vorgehen und es den Parameter StartValue in unserer CounterComponent noch gar nicht gibt, ist unser Test jetzt noch nicht kompilierbar.
[Fact]
public void CurrentCount_IsNotZero_WhenStartValueSet()
{
//Arrange
int startValue = 42;
var componentUnderTest = RenderComponent<CounterComponent>(
parameterBuilder => parameterBuilder.Add(param => param.StartValue, startValue));
//Act
AngleSharp.Dom.IElement paragraph = componentUnderTest.Find("#currentCount");
//Assert
Assert.Equal("Current count: " + startValue, paragraph.InnerHtml);
}
Abbildung 6: Test für unsere Komponente mit einem Parameter
Damit der Test kompiliert, müssen wir unsere Komponente CounterComponenterweitern. Im ersten Schritt fügen wir das Property StartValue vom Typ inthinzu und versehen es mit dem Attribut Parameter. Jetzt kann unsere Komponente kompiliert werden. Anschließend führen wir unseren neuen Test aus und sehen, dass er fehlschlägt. Wir befinden uns also noch in der roten Phase des Red-Green-Refactor-Zyklus von TDD und müssen die Implementierung anpassen. Dazu initialisieren wir unsere Variable currentCountin der Methode OnParametersSet(). Diese Methode wird von Blazor aufgerufen, nachdem die Parameter an eine Komponente übergeben wurden. Jetzt können wir den Test erneut ausführen und sehen, dass er erfolgreich ist. Wir sind also in der grünen Phase unseres TDD-Zyklus. Wir verzichten hier auf Änderungen in der Refactoring-Phase eines TDD-Zyklus.
Die code-behind-Datei unserer Komponente sieht nun so aus:
using Microsoft.AspNetCore.Components;
namespace BlazorWasmTemplateApp.Components
{
public partial class CounterComponent : ComponentBase
{
[Parameter]
public int StartValue { get; set; } = 0;
private int currentCount = 0;
protected override void OnParametersSet()
{
currentCount = StartValue;
}
private void IncrementCount()
{
currentCount++;
}
}
}
Abbildung 7: Die um einen Parameter erweiterte Komponente
Komponenten mit Events testen
Ein weiteres typisches Element von Razor-Komponenten sind Events. Nehmen wir an, dass unsere Website informiert werden möchte, wenn sich der Wert unseres Zählers ändert. Dazu erweitern wir unsere Tests abermals um den folgenden Test:
[Fact]
public void OnCountIncremented_WasInvoked_WhenButtonClicked()
{
//Arrange
bool isEventInvoked = false;
var componentUnderTest = RenderComponent<CounterComponent>(
parameterBuilder => parameterBuilder
.Add(param => param.OnCountIncremented, () => isEventInvoked = true));
AngleSharp.Dom.IElement button = componentUnderTest.Find("#incrementCountButton");
//Act
button.Click();
//Assert
Assert.True(isEventInvoked);
}
Abbildung 8: Test für unsere Komponente mit einem Event
Auch hier ist unser Test noch nicht kompilierbar. Daher ergänzen wir unsere Komponente. Wir fügen das neue Property OnCountIncremented EventCallback hinzu und versehen es wie gehabt mit dem Attribute Parameter. Jetzt ist unser Test kompilierbar, schlägt aber noch fehl. Damit im nächsten Schritt unser neuer Test erfolgreich ist, rufen wir den Callback in der Methode IncrementCount() unserer Component auf.
using Microsoft.AspNetCore.Components;
namespace BlazorWasmTemplateApp.Components
{
public partial class CounterComponent : ComponentBase
{
[Parameter]
public int StartValue { get; set; } = 0;
[Parameter]
public EventCallback OnCountIncremented { get; set; }
private int currentCount = 0;
protected override void OnParametersSet()
{
currentCount = StartValue;
}
private async Task IncrementCount()
{
currentCount++;
await OnCountIncremented.InvokeAsync();
}
}
}
Abbildung 9: Die um einen Event erweiterte Komponente
Subkomponenten
Razor-Komponenten können in sich wieder Razor-Komponenten enthalten (Subkomponenten). Mit bUnit ist es ist möglich, diese Subkomponenten im DOM zu finden, mit Parametern zu versehen, erneut zu rendern und Asserts durchzuführen. Ob solche Tests eine gute Idee sind, hängt vom Szenario ab. Um Abhängigkeiten zu verringern, ist es mit bUnit möglich, Komponenten durch Test Doubles zu ersetzen. Das kann vor allem beim Einsatz von Bibliotheken eines Drittanbieters nützlich sein.
Dependency Injection
Neben Parametern und Events ist es in Razor-Komponenten üblich, Abhängigkeiten durch Dependency Injection zu injizieren. Das Blazor-Framework nutzt dafür die Dependency Injection von ASP.NET Core. bUnit macht deshalb die Services-Kollektion in der Basisklasse TestContext verfügbar, die aus ASP.NET Core bekannt ist. Dort können Test Doubles registriert werden, bevor die Komponente gerendert wird. Für Abhängigkeiten wie IJsRuntime, HttpClient, NavigationManager etc., die den Komponenten normalerweise automatisch durch ASP.NET Core bereitgestellt werden, gibt es Anleitungen für Test Doubles in der Dokumentation von bUnit.
Fazit
Mit bUnit gibt es auch für Blazor eine Möglichkeit, um Komponenten isoliert, schnell und ohne E2E-Tests unter die Lupe zu nehmen. Damit steht für Blazor-Entwickler ein wichtiges Tool zur Verfügung, um mit Tests die Wartbarkeit der Blazor-App sicherzustellen. Außerdem wird es möglich, auch die UI testgetrieben zu entwickeln. Damit steht Blazor auch in diesem Aspekt anderen SPA-Frameworks in nichts nach.
Quellen
[1] nuget.org. [Online]. Available: https://www.nuget.org/packages?q=Tags%3A%22Blazor%22&sortby=totalDownloads-desc. [Zugriff am 22 Juni 2023].
[2] E. Hansen, „bUnit Releases,“ GitHub, [Online]. Available: https://github.com/bUnit-dev/bUnit/releases?page=3. [Zugriff am 22 Juni 2023].
[3] L. Latham, R. Anderson und GitHubPang, „Test Razor components in ASP.NET Core Blazor,“ Microsoft Learn, 04 April 2023. [Online]. Available: https://learn.microsoft.com/en-us/aspnet/core/blazor/test. [Zugriff am 22 Juni 2023].
[4] M. Cohn, Succeeding with Agile: Software Development Using Scrum, Addison-Wesley, 2009.
[5] E. Hansen, „Creating a new bUnit test project,“ bUnit, 7 April 2023. [Online]. Available: https://bunit.dev/docs/getting-started/create-test-project.html. [Zugriff am 22 Juni 2023].
[6] Refsnes Data, „CSS Selector Reference,“ W3Schools, [Online]. Available: https://www.w3schools.com/cssref/css_selectors.php. [Zugriff am 22 Juni 2023].
[7] E. Hansen, „bUnit Documentation,“ 2023. [Online]. Available: https://bunit.dev/docs/getting-started/index.html. [Zugriff am 22 Juni 2023].
