TestAuthenticationStateProvider - make it easy to test components using authentication

[egil]

For components that use the authentication state provider directly or indirectly, there is a lot of boilerplate code to write to create a test, e.g. #135.

Like the MockJsRuntime in bUnit, a TestAuthenticationStateProvider could be provided that allows the user to choose and change the authentication state and user identification for a test.

E.g. something like this:

var authProvider = ctx.Services.AddTestAuthenticationStateProvider(); // defaults to unauthenticated
var authProvider = ctx.Services.AddTestAuthenticationStateProvider("egil"); // defaults to authenticated

Then to change the authenticated state, call:

authProvider.SetAuthenticated(string username);
authProvider.SetUnauthenticated();

@gulbanana has provided us with this sample implementation:

public sealed class TestAuthenticationStateProvider : AuthenticationStateProvider
{
	private string? _username;

	public TestAuthenticationStateProvider(string? username = null)
	{
		_username= username;
	}

	public override Task<AuthenticationState> GetAuthenticationStateAsync()
	{
		if (_username is null)
		{
			return Task.FromResult(new AuthenticationState(new ClaimsPrincipal()));
		}
		else
		{
			var nameClaim = new Claim(ClaimTypes.Name, _username);
			var identity = new ClaimsIdentity(new[] { nameClaim }, AuthenticationTypes.Basic);
			var principal = new ClaimsPrincipal(identity);

			return Task.FromResult(new AuthenticationState(principal));
		}
	}

	public void SetAuthenticated(string username)
	{
		_username = username;
		NotifyAuthenticationStateChanged(GetAuthenticationStateAsync());
	}

	public void SetUnauthenticated()
	{
		_username = null;
		NotifyAuthenticationStateChanged(GetAuthenticationStateAsync());
	}
}

Questions and TODO:

• Does this cover all auth scenarios, e.g. both declarative in razor syntax and in c# code?
• Are there other types of claims that should be supported besides just basic/username? Is it relevant for testing?
• Test that we can correctly switch between authenticated and unauthenticated states.
• Create unit tests that covers the TestAuthenticationStateProvider. This can most likely be a regular unit test, maybe with a single component test in the mix to verify that e.g. AuthorizeView is compatible.
• Create a document page that describe how to use the TestAuthenticationStateProvider
• Create a stub for TestAuthenticationStateProvider (Register stubs of all default services Blazor provides at runtime with useful helper message #115) the is registered by default and provides the user with a good error message that tells how to register TestAuthenticationStateProvider and link to docs. See example from JSMock at:
  • PlaceholderJsRuntime.cs
  • TestServiceProviderExtensions.cs register the stub in the AddDefaultTestContextServices.
• Code should probably be placed in src/bunit.web/TestDoubles/Auth or something similar.
• Create an extension method for TestServiceProvider which supports registering with or without a username, e.g. Services.AddSingleton<TestAuthenticationStateProvider>().AddSingleton<AuthenticationStateProvider>(s => s.GetRequiredService<TestAuthenticationStateProvider>())

[DarthPedro]

That looks reasonable for TestAuthenticationStateProvider, but that is not the only service you need to get CascadingAuthenticationState and AuthorizeView to work in the 4 different states: non-authenticated, authenticated, authorized, unauthorized.

Other required services: IAuthorizationPolicyProvider and IAuthorizationService will need to be added to the TestContext.

[gulbanana]

in a non-test environment, those are usually provided by .AddAuthorizationCore()

[DarthPedro]

I've started work on this scenario in my forked branch. @egil and @gulbanana if you want to take an initial look at the code and provide early feedback, please look here: https://github.com/DarthPedro/bUnit/tree/dev-authorization-fakes/src/bunit.web/TestDoubles/Authorization. @gulbanana if you want to collaborate on this, I can give you access to my fork.

@egil I proceeded with name them FakeXxx based on our gitter discussion. Let me know if you like how that looks. I also placed the code into bunit.web/TestDoubles/Authorization folder (also based on your feedback from the gitter discussion).

I will continue working on this tomorrow with a whole lot of testing.

[DarthPedro]

@egil I also want to add a component test or 2 for a component that uses AuthorizeView. Should I add that to the bunit.web.tests project or is there a different test project that you prefer more end to end types of tests?

[egil]

I've started work on this scenario in my forked branch. @egil and @gulbanana if you want to take an initial look at the code and provide early feedback, please look here: https://github.com/DarthPedro/bUnit/tree/dev-authorization-fakes/src/bunit.web/TestDoubles/Authorization. @gulbanana if you want to collaborate on this, I can give you access to my fork.

To make it easy to provide feedback using the review features in GitHub, just create a draft PR, and I can take a look in that. When you have all the checkboxes ticked in the PR, I will know you consider it done and give a final review.

@egil I proceeded with name them FakeXxx based on our gitter discussion. Let me know if you like how that looks. I also placed the code into bunit.web/TestDoubles/Authorization folder (also based on your feedback from the gitter discussion).

I will continue working on this tomorrow with a whole lot of testing.

Sounds right.

@egil I also want to add a component test or 2 for a component that uses AuthorizeView. Should I add that to the bunit.web.tests project or is there a different test project that you prefer more end to end types of tests?

All related tests to this should be under bunit.web.tests/TestDoubles/Authorization. It makes sense to "attack" it from different angles.

Also, I will be merge master into dev soon, so all the doc changes shows up here as well, so you might need to update your fork.

[egil]

Ps. feel free to copy the "todo" list from this issue into your draft PR so that you can check the boxes as you progress.

[DarthPedro]

@egil For the task: Create a stub for FakeAuthenticationStateProvider (#115) that is registered by default and provides the user with a good error message that tells how to register FakeAuthenticationStateProvider and link to docs.

What do you think about registering an unauthenticated user in AddDefaultTestContextServices rather than creating a stub service? Unauthenticated is truly the state of the user unless they log in, so not sure if a stub is really necessary. What do you think?

[egil]

What do you think about registering an unauthenticated user in AddDefaultTestContextServices rather than creating a stub service? Unauthenticated is truly the state of the user unless they log in, so not sure if a stub is really necessary. What do you think?

My instinct is that we should force users to be explicit in their tests, otherwise they might not be aware that they are in an unauthenticated context, and have a test pass that should not. The dummy auth logic should simply be there in case anybody calls any parts of it and simply throw a good error message explaining how to register the fake and control it. Perhaps even with a link to the page in the docs.

It is important that the dummy doesn't affect tests that do not use any auth.