Blazor Tuesday Tip: Test User Behavior Not Implementation Details With bUnit

As Blazor starts to gain popularity, I see some developers making a common mistake about what they should be testing with bUnit, a testing library for Blazor.


Tip: Test user behavior, not implementation details

To quote Kent C Dodds, author of react-testing-library (a library similar to bUnit but for React):

The more your tests resemble the way your software is used, the more confidence they can give you.

This mantra of course applies to any testing that we do, whether client-side or server-side.  The more you rely on mocks or start testing implementation details, the less confidence you will have that your software behaves how you expect it to.  Moreover, it can make refactoring hard in the future if your tests are tightly coupled with implementation details, because any change in code results in broken tests.


What’s a practical application of this with Blazor?

Let’s say we have a Counter component that I’m sure you’ve seen a million times.  It’s a simple component that simply increments the count by 1 every time a button is clicked:


So we want a test for when the button is clicked, the count is incremented, right?  If you take that test criteria literally, then you might write something like this (note: we’d likely want another test to assert that the initial value is 0):

Run it and it works!  We’re done, right?  Wrong.  This test is testing the implementation detail that CurrentCount is stored in a property of the Countercomponent which is irrelevant to our expected user behavior.


What’s wrong with this assertion?

This test gives us little confidence that the component actually does what we want it to do.  We want to be sure that the CurrentCount is displayed on the screen and increments when the button is clicked.  That assertion does not guarantee CurrentCount is even displayed on the page.

Moreover, this test is brittle.  This test breaks if we change our implementation of where CurrentCount is stored (such as a local variable, injected from DI, local storage, etc.), because our test is tied to our implementation of CurrentCount being a property.


What’s the solution?

Focus on the user behavior.  The behavior we expect is we want to make sure the count increments on the screen, so let’s query the component itself and evaluate the value.

Now our test assures us gives us more confidence, because we are asserting we are displaying the count on the screen AND it’s less brittle for future changes.   It doesn’t matter if we pivot to use some Redux-style state management library or just use a local variable, this test will pass either way.


Hope this helps!  For more reading on avoiding testing implementation details, you can read Kent C. Dodds’ post on Testing Implementation Details.

Globally Require Authenticated Users By Default Using Fallback Policies in ASP.NET Core


You can use Fallback Policies in ASP.NET Core 3.0+ to require an Authenticated User by default. Conceptually, you can think of this as adding an [Authorize] attribute by default to every single Controller and Razor Page ONLY WHEN no other attribute is specified on a Controller or Razor Page (like [AllowAnonymous] or [Authorize(PolicyName="PolicyName")]).  See lines 9-11 below.


A Quick Lap Around the [Authorize] and [AllowAnonymous] Attributes

In ASP.NET Core (and even previously in ASP.NET), we’ve had the ability to add a [Authorize] attribute to a resource (such as a Controller or Razor Page) in order to tell ASP.NET Core not to let a user access that resource unless they are authenticated.

The [Authorize] attribute can also take a PolicyName parameter that tells it what Authorization Policy to execute.  The Policy below says only Admins can access this page.

You can follow this link to learn more how to set up policies in ASP.NET Core and how to enforce your own custom rules (such as what defines an Admin).

By default, if you do not add an [Authorize] attribute, then the resource will not be secured and will be accessible to unauthenticated users.  A resource can also be accessible to unauthenticated users by explicitly adding a [AllowAnonymous] attribute.

Word of Caution: Adding the [AllowAnonymous]attribute bypasses all Authorization, and short-circuits out of the Authorization pipeline, even if Authorization is set further up the stack.


The Problem – Having to remember to add [Authorize] attributes everywhere

When you create a new Controller or Razor Page in ASP.NET Core, by default the resource will be accessible to anyone, because there is no [Authorize] attribute.  This is a problem if you’re creating a site where a majority of the site is protected by some sort of authentication.  It is really easy to forget to add an [Authorize] attribute which could open up your application to a security vulnerability, and leave you with a potential… let’s call it a “resume updating event.” 🙂


What are Fallback Policies?

ASP.NET Core 3.0 turned on Endpoint Routing by default, which was a way to get Routing information out of being tightly coupled to MVC and make Routing more global to the entire stack (such as Middleware).  The 3.0 release introduced the concept of Fallback Policies with Endpoint Routing.

A Fallback Policy means that if no other policy or attribute is specified on a Controller or Razor Page, the Authorization middleware will use the Fallback Policy.  Therefore, if you do not add any other attribute (such as [AllowAnonymous] or [Authorize(PolicyName="PolicyName")], then ASP.NET Core will use the Fallback Policy.


The Solution – Using a Fallback Policy to require authentication by default

So by leveraging a Fallback Policy, we can specify that a user must always be authenticated for every Controller or Razor Page in our application.  You can wire this up under ConfigureServices via the AuthorizationOptions in services.AddAuthorization.   See lines 9-11 below:

Conceptually, you can think of this as adding an [Authorize] attribute by default to every single Controller and Razor Page ONLY WHEN no other attribute is specified on a Controller or Razor Page (like [AllowAnonymous] or [Authorize(PolicyName="PolicyName")]).

Of course, you could also take this one step further, by having your Fallback Policy be a policy that requires certain claims instead of just being authenticated.  The choice is up to you!


What do we gain by doing this?

  1. A more secure default.  A developer doesn’t have to remember to add an [Authorize] attribute to every Controller or Razor Page.
  2. Less boilerplate.  Every Controller and Razor Page requiring authentication has one less line of boilerplate code to worry about.
  3. You don’t give up any flexibility.
    1. If a Controller or Razor Page is supposed to be public to unauthenticated users (such as a Login page or Forgot Password page), then you can still add a [AllowAnonymous] attribute and the Fallback Policy is bypassed.
    2. If a Controller or Razor Page needs a specific policy, you can still add an Authorize attribute with a custom policy name.  That will take precedence over the Fallback Policy such as [Authorize(PolicyName="PolicyName")].


Default Policy vs. Fallback Policy

You might get confused when seeing that there’s also a “Default Policy” in addition to Fallback Policies (or at least I did).  In my head I thought “oh the Fallback Policy is kind of like the default policy that runs… but wait… what’s a Default Policy then?”

The Default Policy is the policy that gets evaluated when authorization is required, but no explicit policy is specified.  In other words, it’s the policy that evaluates when you add an [Authorize] attribute without any PolicyName.  Out of the box, the Default Policy is set to requiring Authenticated Users.

A Fallback Policy, on the other hand, is the policy that gets evaluated if no other policy is specified (such as when no [AllowAnonymous] or [Authorize] attribute exists on a Controller or Razor Page)


The Old Solution in ASP.NET Core 2.x

A common solution to this problem in ASP.NET Core 2.x was to add a Global Filter to MVC such as lines 10-13 below:



In my opinion, the new way using a Fallback Policy makes a lot more sense. It keeps everything inside the Authorization configuration and doesn’t sprinkle Authorization logic into MVC Filters.  The only thing that’s a little goofy is the naming between a Default Policy and Fallback Policy, but once you learn that nuance, the naming makes sense.


In a future post, I’ll go over other tips and tricks for leveraging the ASP.NET Core authorization system.  Stay tuned.

Indented Pretty Print Formatting for JSON in ASP.NET Core


See line 13


The Problem – Readability

By default, JSON in ASP.NET Core will not be indented at all.  By that I mean, the JSON is returned without any spacing or formatting, and in the cheapest way possible (from a “bytes-sent-over-the-wire” perspective).




This is usually what you want when in Production in order to decrease network bandwidth traffic.  However, as the developer, if you’re trying to troubleshoot or parse this data with your eyes, it can be a little difficult to make out what’s what.  Particularly if you have a large dataset and if you’re looking for a needle in a hay stack.


The Solution – Indented Formatting

ASP.NET Core ships with the ability to make the JSON format as indented (aka “pretty print”) to make it more readable.  Further, we can leverage the Environment in ASP.NET Core to only do this when in the Development environment for local troubleshooting and keep the bandwidth down in Production, as well as have the server spend less CPU cycles doing the formatting.

In ASP.NET Core 3.0 using the new System.Text.Json formatter:


In ASP.NET Core 2.2 and prior:


Now when I run the app, the JSON looks much cleaner and easier to read.


Chrome Extensions

There are also Chrome Extensions that will do this for you as well when you navigate to a URL that returns an application/json Content-Type.  Some extensions add more formatting capabilities (such as colorization and collapsing).  For instance, I use JSON Formatter as my go-to extension for this.



Closing – So why do I need this if I have the Chrome Extension?

While I use the JSON Formatter extension, I still like setting the indented format in ASP.NET Core for a few reasons:

  1. Not all of my team members use the same Chrome extensions I do.
  2. The formatting in ASP.NET Core will make it show up the same everywhere – the browser (visiting the API URL directly), DevTools, Fiddler, etc.  JSON Formatter only works in Chrome when hitting the API URL directly (not viewing it in DevTools).
  3. Some applications I work on use JWT’s stored in local or session storage, so JSON Formatter doesn’t help me out here.  JSON Formatter only works when I can navigate to the API URL directly, which works fine when I’m using Cookie auth or an API with no auth, but that does not work when I’m using JWT’s which don’t get auto-shipped to the server like Cookies do.


Hope this helps!