Testing @bind updates

[uecasm]

Given this component:

<span>@Value</span>

@code {

    [Parameter] public string? Value { get; set; }
    [Parameter] public EventCallback<string?> ValueChanged { get; set; }

    public async Task Set(string? value)
    {
        await ValueChanged.InvokeAsync(value);
    }

}

And these NUnit tests:

@using NUnit.Framework
@using Bunit
@*@inherits Bunit.TestContext*@
@inherits BunitTestContext /* this uses TestContextWrapper */
@code {

    [Test]
    public void UnboundValue()
    {
        using var cut = Render<BindComponent>(@<BindComponent Value="test"/>);

        cut.MarkupMatches(@<span>test</span>);
    }

    [Test]
    public void BoundValueFromOutside()
    {
        var value = "test";

        using var cut = Render<BindComponent>(@<BindComponent @bind-Value="value" />);

        cut.MarkupMatches(@<span>test</span>);

        value = "another";

        cut.Render();
        cut.MarkupMatches(@<span>another</span>);
    }

    [Test]
    public async Task BoundValueFromInside()
    {
        var value = "test";

        using var cut = Render<BindComponent>(@<BindComponent @bind-Value="value" />);

        cut.MarkupMatches(@<span>test</span>);

        await cut.Instance.Set("another");

        Assert.That(value, Is.EqualTo("another"));
        cut.Render();
        cut.MarkupMatches(@<span>another</span>);
    }
}

The two Bound tests fail (reporting no change to the rendered content -- still showing "test"). What am I missing?

For BoundValueFromOutside, I'm expecting that some explicit call is needed (since there's no internal StateHasChanged), and I was expecting that Render would pick up the new value and render that, but it appears it does not.

For BoundValueFromInside, I'm expecting that there shouldn't need to be any call (since EventCallback should internally trigger StateHasChanged) but I included an explicit Render anyway, but it doesn't help.

Perhaps notably, the SetParameters lifecycle method is called again for the second render but still with the old value.

If I explicitly SetParametersAndRender then it produces the correct output, but this means repeating the parameter assignments, which shouldn't be necessary when binding.

Of interest is that if I add a wrapping component:

<BindComponent @bind-Value="Value" />
@code {
    public string? Value { get; set; }  // intentionally not a Parameter
}

With this test:

    [Test]
    public async Task BoundValueFromWrapper()
    {
        using var cut = Render<BoundComponent>(@<BoundComponent/>);

        cut.MarkupMatches("<span></span>");

        cut.Instance.Value = "test";
        cut.Render();
        cut.MarkupMatches("<span>test</span>");

        await cut.InvokeAsync(() => cut.FindComponent<BindComponent>().Instance.Set("another"));

        Assert.That(cut.Instance.Value, Is.EqualTo("another"));
        cut.MarkupMatches("<span>another</span");
    }

This variant includes two changes to Value -- the first is similar to BoundValueFromOutside and the second is similar to BoundValueFromInside. But now this all passes, without requiring explicit re-render after the internal Set (as expected) -- but it does fail (call on wrong thread) if Set is called directly rather than invoked (which wasn't entirely expected, but seems reasonable).

It does seem odd that a top-level component under test behaves differently from a wrapped component, though.

[linkdotnet]

There seems to be a few misconceptions how Blazor works here. Let's start with the second failing test BoundValueFromInside, where you expect a change of your Parameter. But your code never does that:

public async Task Set(string? value)
{
+ Value = value; // You have to set your parameter as well
  await ValueChanged.InvokeAsync(value);
}

If you check how the @bind directive works internally you will find something like this:

builder.OpenComponent<...MyComponent>(10);

builder.AddAttribute(11, "Value", 
  ...TypeCheck<System.String>(
    ...BindMethods.GetValue(someVariable)
  )
);

builder.AddAttribute(12, "ValueChanged",
  ...TypeCheck<...EventCallback<System.String>>(
    ...EventCallback.Factory.Create<System.String>(
      this,
      ...EventCallback.Factory.CreateInferred(
        this,
        \_\_value => current = \_\_value,
        current
      )
    )
  )
);
builder.CloseComponent();

That is why just invoking the event doesn't cut it. Blazor doesn't do something magically in that sense. Now why is your first Bound test failing. Well, setting the value from the outside and just calling render is not what Blazor does. If you change a variable you have to call SetParametersAndRender. That is what Blazor would do in your case. The two-way binding, just from the view of the parent in the parent-child relationship, is nothing special. Even if you don't have a two-way binding, but a classical one-way binding, your test would not work.

The two-way binding is only useful if you want to bubble up the value to the parent again.
In your special case you are also using a string - they are immutable. So setting them somewhere outside of the Blazor context, will likely not do what you would expect.

Here an example: Parent.razor

<p>@text</p>
<Child Text="@text"></Child>

<button @onclick="() => StateHasChanged()">Update Parent</button>

@code {
    private string text = "Test";
}

Child.razor:

<p>@Text</p>

@code {
    [Parameter]
    public string Text { get; set; }

    protected override void OnParametersSet()
    {
        Text = "New Content";
        StateHasChanged();
    }
}

The output will always be:

Test

New Content

Even if you press the button and force Blazor to check everything again.

[uecasm]

There seems to be a few misconceptions how Blazor works here. Let's start with the second failing test BoundValueFromInside, where you expect a change of your Parameter. But your code never does that:

That's not correct. In fact the Blazor docs very strongly caution you to never write to your own parameter properties.

Again, note that the code works perfectly inside of another Blazor component (the last test), where calling the event will update the internal (non-parameter) property (this is equivalent to a private field, it's just exposed for convenience of the tests), and then the subsequent render will use the new value, without any extra steps. It's only at the bUnit top level that this standard behaviour no longer applies.

I suspect what's going wrong here is that EventCallback checks the callee object passed in and ComponentBase is set up such that StateHasChanged (on the parent) is triggered when this happens, which is what triggers the full re-render of the parent, passing the new parameter value to the child. If the wrapper component added by bUnit doesn't do the same, perhaps even the explicit call to Render is being ignored because it thinks it's already up to date.

In your special case you are also using a string - they are immutable.

That's irrelevant; replacing a reference value with a different reference will also bubble down from the parent to the child.

<button @OnClick="() => StateHasChanged()">Update Parent

That's pointless; event handlers will call StateHasChanged automatically unless you take extra steps (due to EventCallback being the standard event handler).

The rest of your example is not even slightly the same case as what I'm reporting. And you're assigning to the child parameter property, which as already noted is not legal.