8. Unit Testing

Requirements

Sometimes bugs are introduced even before a single line of code is written. Writing good requirements is hard, because these need to explain business concepts to developers who are typically not well versed in this domain. The same thing counts for advanced engineering concepts, like rocket building. Let’s look at an example. NASA lost its $125,000,000 Mars Climate Orbiter because of a simple missing piece of information in the requirements: which units to use. One team was using metric units (meters, kilogram), while another team was using imperial units (inch, pounds), and there was no conversion in place because each team thought the other team was using the same units! You can read more about it here: www.latimes.com/archives/la-xpm-1999-oct-01-mn-17288-story.html.

This bug could easily be averted! Since the specifications never mentioned the units, if someone had asked which units to use and add this to the specifications, this Mars Climate Orbiter would probably be spinning around Mars right now! So as a developer, if you think something is confusing or ambiguous, ask! Never assume anything!

Coding

It is easy to introduce bugs during coding. That is part of developing software. Code that was working very well can become buggy by a benign change. So how can we discover these bugs? We should automate our testing. By writing a piece of code (a unit test) that checks if another piece of code is behaving as expected, we can run this test every day and discover the bug hours after it was written. Have you ever received a bug report about some functionality you wrote three months ago? You will probably rub your head wondering what you were trying to do (and you write this code!). After studying your code for a while, understanding kicks in and you fix the bug (let us say a simple one-off bug). Now imagine the bug is discovered an hour after you made the change. Do you need to figure out what your code was doing? No, it is still fresh in your memory. That makes unit testing so efficient. And when you finish your code and all your unit tests are green (meaning check out OK), you can go home and sleep soundly!

Same thing counts for refactoring code. I mean, cleaning up some code and keeping the same functionality. How do you know if you introduced bugs while refactoring when there are no unit tests? If there are unit tests and they all pass before refactoring, it is easy to see after refactoring if you broke something. Just run the unit tests, and if they all pass, you did not break anything that was known to be working! Again, you can go home and sleep knowing you made your code more maintainable and did not introduce any new bugs!

Integration

Your code works on your machine. And your colleague’s code also works on their machine. But will your code work together with your colleague’s code? That is what integration is all about. A long time ago, teams would integrate code from different teams at the end of the project. Guess what!? This never went well, resulting in project overruns, sometimes by months. So development teams started to integrate at the end of each month and then at the end of the week. Integrations started to become automated using build systems. Now we can do continuous integration where we integrate changes to the code after each commit in source code. And when we have unit tests, we can run these after the compilation ends and use that to catch breaking changes. Again, this should illustrate the role of good unit tests. You use them to see if your code is working and also to see if everyone’s code keeps on working.

Beta Testing

At a certain point in time, you should expose end users to your application. Why? Because developers are not normal people. End users want things to be as simple as possible. For example, look at google.com. This site only has one text box where you type your question and a button to do the search. This simplicity made Google the most used search engine (sorry Microsoft). Developers are control freaks; they want power, not simplicity! Just open the options screen in Visual Studio. You can tweak just about anything! And most end users are not as proficient using computers as developers, sometimes resulting in surprises. Let me tell you about a personal experience I once had. We had built software that runs in a factory, and on a Sunday (they work in that factory continuously), I get a call from an end user. He told me “The button does not work!”. After half an hour on the phone, I decided to drive over there and see for myself. I get there and I click the button, and it works! So what was the problem? The button was small because we needed to cram a lot on the screen, and the end user has a bit of a tremor and moved the mouse when clicking, resulting in a click outside of the button. So we fixed the bug by making the button bigger. This is a nice example of a usability problem, where we as developers are not always aware of. So expose your software to your users often, and gain their feedback. We are building it for our end users, right?

Post-release

Perfect software does not exist. Have you ever writing an application that is bug-free? No? I have! It is called “Hello World!”. Anything beyond that is impossible. But having an end user discover a bug is bad news. It will lower the trust in the development team and in the quality of the software. So how do we stop bugs from making it into production? You can’t! The only thing you can do is to test as much as possible and warn the users that they may encounter bugs, especially early after release.

What Makes a Good Unit Test?

When you practice unit testing, your development life cycle looks like this: make some change to the code, build, fix compiler errors, build again, and then run all your tests. Then fix the bugs discovered by your tests. And then you start again. How long does building your application take? A couple of seconds? Now imagine that your unit tests take 5 minutes. Would you want to wait for that? Would you be tempted to disable running the unit tests? A good unit test should be fast so we don’t have to wait very long. What makes unit tests slow? Typically, this is caused by accessing slow resources, like databases, disks, and the network. So with a unit test, we will avoid using slow resources. What if your unit tests need some setup? Every time you need to run the tests, you would have to prepare some things manually. Again, we don’t have time for that. A good unit test should also be automatic and repeatable , meaning that the test should report on success or failure and that again we avoid things that need some manual setup. What could that be? Again databases, files on disk, and the network! Another aspect of a good unit test is consistency . If your unit test fails, this should be because of a bug in your code, not because someone tripped over a network cable making the database or network inaccessible! So again, we should avoid things like databases, file shares, and networks.

Tests which do not have all the aspects from earlier do exist. You will have to write a test to interact with the database (but don’t start testing the framework used to access the database; that is the framework’s author’s job!). Their tests are known as integration tests , because we will run them during the build, not during the development life cycle.

Adding a Unit Test Project

Let us look at an example using xUnit , which is a popular testing library for .NET which we will also use for testing our Blazor components.

When you are using Visual Studio, right-click the test folder and select Add new project. In the Add New Project dialog, search for the xUnit Test Project template. Now click Next. Set the Location to the test folder and name it Testing.ComponentTests.

Adding bUnit to the Test Project

With the current unit test project, we can test our services and other non-Blazor classes. In order to test Blazor components, we need to add bUnit . So use your favorite method to add the bUnit package (choose latest stable version).

Writing Good Unit Test Methods

Every unit test will consist of three phases: Arrange, Act, and Assert, also known as the triple A of unit testing . The Arrange phase will set up the unit test by creating the subject under test (SUT), by which I mean the class we want to test and its dependencies. The Act phase will perform the call on the method we want to test, and the Assert will verify if the outcome is successful.

Running Your Tests

With Visual Studio, open the Test Explorer window (Test ➤ Test Explorer) as in Figure 8-2. With Visual Studio, Test Explorer is the place to run unit tests and review the results. After opening Test Explorer, it will scan your solution for unit tests and list them. Now click the left green arrow in this window to run all your tests.

The test will run and fail as shown in Figure 8-3.

You can also run unit tests from Visual Studio Code, but you will have to install the .NET Core Test Explorer extension as shown in Figure 8-4.

Now you can run your tests by clicking the Test Explorer icon in the left side of VSC as shown in Figure 8-5.

VSC Test Explorer will display a couple of buttons as shown in Figure 8-6. From left to right, you have a button to run the tests, refresh the list of available tests, stop test execution, and show the log with the test results.

Click the play icon to run the test. The test will run and fail. To see the result of the test, click the log button and then check out the PROBLEMS tab as shown in Figure 8-7.

Making Your Test Pass

Now run the test again (with or without the debugger). Now it should pass as in Figures 8-8 and 8-9.

Using Facts and Theories

Now when we run our tests, you will see in Figures 8-10 and 8-11 that xUnit runs three tests, one for each [InlineData] attribute.

Checking Your Sanity

But when we run, the test fails as in Figure 8-12.

Run your test again. Now it passes. Whew! This was actually normal behavior.

Unit testing is great to discover these weird behaviors and allows you to catch modifications that cause bugs later.

Understanding bUnit?

bUnit is a testing library for Blazor components, written by Egil Hansen, and the sources can be found in GitHub at https://github.com/bUnit-dev/bUnit. With bUnit, you can easily write unit tests for Blazor components. Why should we write unit tests for Blazor components? Same reason you write unit tests for regular classes: to ensure they work as expected and that they keep on working in case some dependency gets updated. Of course, most of your testing should be on the service classes that implement business logic. For example, you want to make sure your Blazor component calls a certain method on a service when the user interacts with that component. With bUnit, we can automate that so no user has to actually click a button! And we can run these tests continuously so we will know when we break a component minutes after the change.

Part of testing a Blazor component is to render and examine the output of a component. But it goes way beyond this. You can interact with the component and see the changes, replace dependencies, etc.

Here, we are using xUnit together with bUnit, so our unit test has the [Fact] attribute. First, we do the Arrange phase, where we create the component under test (which I name cut, similar to sut) by calling the RenderComponent<Counter> method. This will create the component and render it in one go. So this also takes care of the Act phase. Next, we do the Assert phase, where we want to see if the component generated the right kind of output.

This test will fail. Why? Just run the test, and look at the test output as in Figure 8-13. Look again at the Assert statement in Listing 8-10. Here, we expect the markup of our component to match the literal string. And it does match in a way, except for whitespace and newlines. We could now do the work and update our string to the real output, but this is too sensitive to little changes we might make later to our component.

Run your tests and see if they pass, which they should.

What happens when the test fails?

In the RenderParagraphCorrectlyWithInitialZero method , replace the 0 with a 1. Run the test. It fails! Select the test and you should see the following output as in Figure 8-14. This output shows us what is wrong, and now we can change the component (or the test) until the test passes. Fix the test.

Testing Component Interaction

The bUnit library comes with many dispatch methods that make it possible to trigger events on your component. Retrieve the element in the component using the Find method, and then call the appropriate dispatch method on it, for example, Click. These dispatch methods also allow you to pass event arguments. So let us look at an example.

In the unit test project, add a new class called MouseTrackerShould with a single unit test as in Listing 8-16. During the Arrange phase of the bUnit test, we create an instance of MouseEventArgs with ClientX and ClientY set to some value. We then create an instance of the MouseTracker component using the TestContext’s RenderComponent method. Now we Find the div from the component and store it in the theDiv reference.

Run the test; it should pass.

Passing Parameters to Our Component

This way of passing parameters to a component is very convenient, since we can use IntelliSense to choose the parameter’s name. There are other ways to pass the parameters, as shown in Listing 8-19. Here, we use xUnit’s Theory to pass different parameters to the component, and each parameter is passed as a ValueTuple, containing the name and value of each parameter (that is why these are wrapped in an opening and closing parenthesis).

Testing Two-Way Data Binding and Events

Our TwoWayCounter has parameters to implement two-way data binding. Let us see if this component implements this correctly. We can use the same technique as before to pass handlers to the CurrentCountChanged and IncrementChanged parameters. But before we do this, add the FluentAssertions package to your test project. FluentAssertions allows you to write your assert statements in a more readable and concise way, and we will use it here (although this is not required). You can find out more about fluent assertions at https://fluentassertions.com.

Look at the bUnit test from Listing 8-21. We are adding four parameters, where two of them are of type EventCallback<int>. We assign a value to the EventCallback<int> using a delegate, and this delegate increments a local variable. This way, we count the number of invocations of the CurrentCountChanged and IncrementChanged event callback.

Testing Components that Use RenderFragment

Should the Alert component have additional parameters, we can pass the just like in Listing 8-18.

But what about the ItemContent parameter which uses the more complex RenderFragment<TItem>? Add a new unit test as in Listing 8-31. Here, we will pass five strings using the loader Func<ValueTask<IEnumerable<string>>>. Do note the use of the Enumerable.Repeat method to create a collection of elements. We pass the loader as a parameter to the TemplatedList<string> component, and we also pass the ItemContent, which is a RenderFragment<string>. Since this takes an argument, we use a Func<string, string> delegate which will return a RenderFragment<string> (because the Add method takes care of this).

Run this test; it should normally pass. And if it does not, we will discuss this in the section “Handling Asynchronous Re-renders,” so keep reading.

So the first argument is tl => tl.ItemContent which returns the parameter to set. The second argument is a lambda function, which takes the value for TItem (so in our case, a string), and returns another lambda function which takes a ComponentParameterCollectionBuilder<TComponent>. Does this sound familiar? Yes. It is the same type we have used to pass parameters to a component from the beginning of this section (Listing 8-18 example). Here, we add parameters to the ListItem component by calling Add.

Run this test (and the others if you like). All tests should pass. Phew!

Using Cascading Parameters

Injecting Dependencies with bUnit

When you use this component in a Blazor application, the Blazor runtime will take care of injecting this dependency. When you use the component in a bUnit test, the bUnit runtime will take care of injecting the dependency. The only thing we need to tell is which class to use to instantiate the instance.

Replacing Dependencies with Fake Objects

When you are testing a component, you want full control over dependencies. This means in many cases that you cannot use the real dependency. First of all, remember that tests should be fast and automatic? If the real dependency uses a database or a REST call to fetch data, this will make your test slow. Networks, disks, and databases are several factors slower than accessing data from memory. So we want to avoid these things. Also, databases and disks have memory, so when a test makes modifications to the data, the next time the test runs, it is using different data and will probably fail. So we don’t want to use the real dependency (we are testing the component, not the dependency!). So we will use a fake implementation of the dependency, and that is why it is so important to have your dependencies implement an interface. Building another class with the same interface is easy and practical.

And there are different kinds of fake objects. Let us discuss stubs and mocks as shown in Figure 8-15. As you can see, both stubs and mocks are special cases of fake objects. The terminology (stub, mock, fake) used here unfortunately is not consistent in the testing community. Some people classify fake object using different names, and some people even use taxonomies containing seven different kinds of stubs!

Using Stubs

Let us start with stubs. A stub is a fake implementation of a dependency that is just there to assist in a test. Our FetchData component will fetch a couple of forecasts from the IWeatherService dependency. But how many forecasts will this return? If we use the real service, this might depend on a bunch of things which are out of our control. So we use a stub implementation of the IWeatherService where we have full control. The stub is just there to assist in the test, and we will perform our Assert phase on the subject under test, not the stub. Let me use another example. Imagine you work for a car company, and you want to test your new type of car for safety. You want to run this car into a wall and see if it will explode (like in the movies). Will you run the car into a real wall? Someone’s house? No. You will have someone build a fake wall in a controlled environment so no one will risk getting hurt. You drive the car into the wall, and then the wall has served its purpose. You will examine the car to see the outcome of the test; the wall is no longer important. This is illustrated in Figure 8-16.

Tests that use stubs are also known as state verification tests .

Let us build a stub for the IWeatherService . Start by adding a new class called WeatherServiceStub to the test project.

Run the test. It should pass.

Using Mocks

So what is a mock? A mock is a fake implementation where we want to verify if the subject under test called certain methods and properties on the mock. A mock therefore works a little like a data recorder, remembering which methods were called, even recording the values of the arguments in the method call. It should not come as a surprise that building a mock is a lot more work! When you use a mock in a test, you will do your Assert phase through the mock, with questions like “Did the subject under test call this method?” Let us use the car example again. Now we want to see if the driver of the car gets hurt in a frontal crash into a wall. We already have a wall, but now we need a driver. Any volunteers? No? Of course, not. We will mimic the driver (a mock object) using a crash test dummy. These dummies look a lot like a human (if you are Homer Simpson) and are crammed full of sensors. You let the car crash into the wall. After the crash, you are not interested in the wall, neither the car. You will ask the dummy (the mock remember) where it hurts. Again, this is illustrated in Figure 8-17.

Tests like these are known as object interaction tests .

So we create a stub for the IWeatherService , a mock for the ILogger, and then we render the component. Now we want to check the Journal of the LoggerMock. There should be one call to the logger, so we check the length of the Journal. Then we check the entry’s state to see if it contains the message. All straight forward but a lot of work!

Run all your tests. The UseWeatherService test breaks! Why? Because we introduced another dependency, so we need to dependency inject a logger in this test too. I will leave the fixing in your capable hands.

Implementing Stubs and Mocks with MOQ

How can we implement stubs and mocks with a lot less work? Other people have been asking the same question, and some of them built libraries that make this possible. Generally, these libraries are known as isolation frameworks . Isolation frameworks allow you to quickly generate stubs and mocks for classes and interfaces, where you implement just the methods you need for the test, and verify if the subject under test invoked methods with certain arguments a certain number of times. Here, we will look at MOQ which is currently one of the most popular in the testing community. We will cover a lot of features of MOQ here, but if you want to learn more, you can visit https://documentation.help/Moq.

Start by adding the MOQ NuGet package to the test project. Now copy the UseWeatherServices method and rename it to UseWeatherServicesMOQ. Change its implementation like Listing 8-45. First, we create the forecasts data we want the IWeatherService to return. Next, we create an instance of Mock<IWeatherService> which is a class from MOQ. This class allows us to Setup methods from the interface and Returns a certain result. It is that simple to provide a stub implementation. But MOQ allows you to go further and makes the method return different results, depending on the arguments, for example.

Next, we configure bUnit’s dependency injection to inject a singleton instance, passing the stub.Object, which is an instance implementing the IWeatherService interface. No need to build our own class to create a stub.

Run the test; it should pass.

Run the test. It should pass.

The First Razor Test

In your test project, add a new razor component called RCounterShould as in Listing 8-48. Here, I will prefix the razor unit tests with an R, so we don’t get a name conflict with our other CounterShould test class. We will make the test inherit from TestContext, just like our test classes written in C#. Then we add a @code section and put our xUnit test method in there. Because this is a razor file, we can write the test’s markup using razor inside the Render method.

Why Do We Need Semantic Comparison?

Using strings to compare markup is too sensitive to small changes in the markup. For example, formatting your code might add some whitespace, and since string comparison will compare each character, a working test will suddenly fail. And there are many more innocent changes that will break a test, for example, changing the order of attributes, or reordering the classes in the class attribute, or adding comments. Semantic comparison will ignore all of these changes, resulting in tests that will not break because of a simple change.

Customizing Semantic Comparison

By default, semantic comparison will ignore whitespace, but in some cases, you want to verify if the component actually renders some whitespace. Do this with diff:whitespace="preserve".

You can also tell semantic comparison to ignore case or use a regular expression for your comparison.