Testing Blazor WebAssembly Apps

Testing is an essential process in software development that helps ensure that the application functions as expected and meets the desired quality standards. In this chapter, we will briefly introduce the concept of testing software, the different types of testing, and their importance, and then we will take a deep dive into testing Blazor WebAssembly apps.

This chapter will introduce you to the bUnit library, which is used for writing unit tests for Blazor components, and then we will start writing some unit tests that cover different scenarios and different types of components. We will learn advanced concepts in unit testing, such as mocking and faking using Moq, and we will cover the built-in services in bUnit in addition to writing unit tests that cover those features. Lastly, we will briefly introduce the Playwright library and end-to-end (E2E) testing in Blazor WebAssembly.

This chapter will cover the following topics:

• Testing Blazor...

Technical requirements

The Blazor WebAssembly code and the API project used throughout this chapter are available in the book’s GitHub repository in the folder for Chapter 13:

https://github.com/PacktPublishing/Mastering-Blazor-WebAssembly/tree/main/Chapter_13/

Testing Blazor components overview

Testing software is a crucial part of the development process, not only in SPAs and Blazor WebAssembly but in all elements of software. Testing as a term has multiple meanings and approaches in the software industry and long books could be written about it, but we will focus on component testing developed in Blazor WebAssembly. We will examine the two testing types: unit testing and E2E testing.

For every feature we have developed so far, if we run the project, navigate to the target page or component, and use it to see if it will behave as expected, we are only conducting one type of testing. This type of testing is called end user testing, which is not reliable. To ensure the app logic, behavior, and components are working as expected, tests should be written at the code level, so more common and rare scenarios can be simulated.

The first type of testing we will examine is called unit testing, which is a fundamental type of testing in software...

Getting started with testing in Blazor with bUnit

Blazor doesn’t have a native unit testing framework, so its great community came up with bUnit, which became the standard for testing Blazor apps.

bUnit allows you to write unit tests either in C# files or in Razor components, and it’s compatible with all the common testing frameworks, such as xUnit, NUnit, and MSTest.

While testing a component, bUnit renders the target component in isolation and provides a full simulation, such as passing parameters, cascading values, and injecting services. It also simulates interactions with the component, such as clicking buttons or triggering event handlers.

The component being tested is known as the Component Under Test (CUT). The term CUT is what we will use throughout this chapter to name the component that we are testing. The term CUT is derived from the term Service Under Test (SUT), which is a known term in testing software overall, not just UI components.

After...

Writing component unit tests with bUnit

We have seen the basic tests written by default in the bUnit template. In this section, we will start creating our own tests. We’ll write a test for the ModalPopup component we developed in the Developing templated components section in Chapter 3, Developing Advanced Components in Blazor.

Writing the first component unit test

ModalPopup is a good starting point for us as it doesn’t have dependencies and it has some parameters, so we can learn how to pass parameters to a CUT.

Let’s get started:

1. In the BooksStore.Tests project, add the BooksStore namespaces needed inside _Imports.razor so we don’t need to reference them in each test file we have:

   ...@using BooksStore.Shared@using BooksStore.Models@using BooksStore.Services

2. Create a new Razor component and name it ModalPopupTests.razor.
3. Remove any markup and make the component inherit from the TestContext class:

   @inherits TestContext@code {}

4. Inside...

Mocking and faking tests in Blazor and bUnit

Writing stable unit tests requires isolation for the unit under test as the unit tests should run frequently in different environments and on different machines. So, to keep the tests reliable, they should be written in isolation from external factors such as communicating with an API or asking for an access token.

Mocking and faking are the keys to simulating the behavior of the dependencies of the unit under test. For example, the Index page depends on IBooksService, and the implementation we have is called BooksHttpClientService, which sends requests to the API to fetch the books needed for the Index page. If we want to test IBooksService, we need to mock it and write a fake implementation for the GetAllBooksAsync method so the unit test can rely on this fake service instead of the actual API.

In order to mock services in .NET, there are many available packages, but Moq is the most common one, and it’s the one we will be...

Introducing Playwright for E2E tests

In E2E tests, we need to ensure that our system is fully behaving as expected, including the interaction with external services, such as the web API.

Even though unit testing is more crucial than E2E testing, a great testing strategy includes all different types of tests, including unit tests, integration tests, E2E tests, and performance tests. The reason why automated E2E tests are less important than unit tests is that all the components have to be available and running. In our case, every time you want to run E2E tests, the API has to be up and running, and a sandbox environment has to be available, otherwise the tests will keep adding, editing, or deleting data if the API doesn’t support test data. E2E tests are also slower to run, so running them all the time, as we can with unit tests, is not preferable.

E2E tests complement rather than replace unit tests for the product’s overall testing. E2E testing is not meant to replace...

Summary

Throughout this chapter, we have learned about testing software and especially Blazor WebAssembly components. First, we introduced the concept of testing, why it’s important, and the difference between unit testing and E2E testing. Then we introduced bUnit and set up the testing project. After that, we discovered the default tests written in a bUnit testing project template before starting to write our own, while learning gradually about bUnit’s features. While writing tests, we saw the need for mocking and faking services and features to satisfy the CUT. We learned about the Moq framework and the built-in mocking and faking services within bUnit. Finally, we introduced the Playwright library for .NET, which we can use to write E2E tests in Blazor WebAssembly.

After completing this chapter, you should be able to do the following:

• Understand the importance of testing software
• Be familiar with the bUnit library and its features
• Write unit tests...

Further reading

• Testing Razor components in ASP.NET Core Blazor: https://learn.microsoft.com/en-us/aspnet/core/blazor/test?view=aspnetcore-7.0
• bUnit documentation: https://bunit.dev/docs/getting-started/index.html
• Playwright for .NET: https://playwright.dev/dotnet/docs/intro
• Testing Blazor applications with Playwright: https://learn.microsoft.com/en-us/events/dotnetconf-2022/testing-blazor-applications-with-playwright