Parameter not read from route

[JamesNK]

Describe the bug

I have a page that I'm testing with some routes:

@page "/metrics"
@page "/metrics/resource/{ApplicationName}"

There are also some query string parameters:

[Parameter]
public string? ApplicationName { get; set; }

[Parameter]
[SupplyParameterFromQuery(Name = "meter")]
public string? MeterName { get; set; }

I have set a URL in navigation manager:

var navigationManager = Services.GetRequiredService<NavigationManager>();
navigationManager.NavigateTo("/metrics/resource/TestApp?meter=foo");

When the component is rendered I see the MeterName parameter has a value, but the ApplicationName is blank.

Now, I can fix that by manually setting the parameter value when calling RenderComponent:

var cut = RenderComponent<Metrics>(builder =>
{
    builder.Add(m => m.ApplicationName, "TestApp");
});

But part of the code I'm testing changes the current page with NavigateTo, and I need ApplicationName parameter to pick up its new value when navigation happens.

Why isn't ApplicationName parameter value getting its value from the @page "/metrics/resource/{ApplicationName}" page route?

[linkdotnet]

Hey @JamesNK,

the short answer on why it doesn't get the parameter value from the attribute is because there is no Router involved in bUnit, and the way you did this is (currently) more or less the intended way.

The long answer is here: https://bunit.dev/docs/providing-input/passing-parameters-to-components.html?q=SupplyParameterFromQuery&tabs=csharp#passing-query-parameters-supplyparameterfromquery-to-a-component

Since net8.0, the ParameterAttribute isn't mandatory anymore when SupplyParameterFromQueryAttribute is used, as itself inherits from CascasdingParameterAttribute.

This whole cascade is handled by the NavigationManager. But your ApplicationName isn't - it is resolved by the router, which bUnit doesn't have at all.

Therefore, as you provided the ParameterAttribute on MeterName you should be able to do the following:

var cut = RenderComponent<Metrics>(builder =>
{
    builder.Add(m => m.ApplicationName, "TestApp");
    builder.Add(m => m.MeterName, "Some Value");
});

If you drop the ParameterAttribute then you already do what you "should" do.

The reasoning behind is that the whole @page setup is a 3rd party concern from the point of view of your code, and falls under the same category as JavaScript or CSS stuff (which are also left out in a bUnit test).

Maybe @egil and I can pick this up tomorrow and discuss this further. At least from a documentation point of view, there is room for improvements.

[JamesNK]

Ok. This is what I added to make my test pass:

        navigationManager.LocationChanged += (sender, e) =>
        {
            cut.SetParametersAndRender(builder =>
            {
                builder.Add(m => m.ApplicationName, "TestApp2");
            });
        };

It's surprising that some parameters are automatically bound from navigation manager and others aren't.

[egil]

@JamesNK, I think it is a decent workaround to emulate NavigationManager's behavior in production like that.

Do I understand the scenario correctly: A component under test uses NavigationManager to change the URL. In production, this would cause the component's (page) life cycle methods (OnParameterSet, etc.) to be triggered, and parameters defined in the URL updated on the component under test.

In a bUnit test, only SupplyParameterFromQuery parameters are updated, not "path" parameters?

It's surprising that some parameters are automatically bound from navigation manager and others aren't.

It is, and I dislike that. Prefer not to surprise users. As far as I can tell (or remember), our FakeNavigationManager does not do anything to support automatically updating SupplyParameterFromQuery parameters when its NavigateTo methods are called, so I am guessing that the core Blazor renderer does this for us.

I think it should be possible to enable this for path parameters too, since our renderer could subscribe to LocationChanged and trigger a re-render of any components it has rendered if they have a PageAttribute with path parameters. It would probably be a breaking change for v1 users if enabled by default though.

[JamesNK]

Do I understand the scenario correctly: A component under test uses NavigationManager to change the URL. In production, this would cause the component's (page) life cycle methods (OnParameterSet, etc.) to be triggered, and parameters defined in the URL updated on the component under test.

Yes

[linkdotnet]

I will officially tag this as v2 as the open PR will be simpler with the work we have done on v2.

[linkdotnet]

@JamesNK We had a look at this after quite some time and we decided that we are not going to directly address the NavigateTo issue. The issue we have is that we can't satisfy and make it transparent enough.

Imagine the following scenario:

var navigationManager = Services.GetRequiredService<NavigationManager>();
navigationManager.NavigateTo("/metrics/resource/TestApp?meter=foo");

var cut = Render<Metrics>();

Should ApplicationName be set to TestApp here?

Furthermore, bUnit does not navigate in the literal sense as a browser would do. So navigating away to a different @page component will absolutely not work.

We think that in your case, you want to test the mapping between the provided parameters and the specified route parts, correct?

If so, we might come around with some kind of Verify method that does that for you.

From bUnit's POV: The "manual setting" as you described it is the more idiomatic and preferred one.

[egil]

In addition, what if users navigationManager.NavigateTo("/path/not/related/to/component/under/test");, should bUnit try to render the component that matches that URL. It could, but since NavigateTo does not return an IRenderedFragment, the experience isnt really that.

As Steven mentions, there is value in validating that parameters declared in routes have matching [Parameter] properties, since these connections are stringly-typed. Ideally, somebody should create a Blazor analyzer that validates this at build time.

Alternatively, a generic test that uses reflection can be created that does this.

But again, adding the feature to NavigateTo have too many implications and hidden behavior that is likely going to cause confusion for end users. The right approach is to set parameters from the RenderComponent method.