How to wait for parameter's setter to execute?

[anddrzejb]

I started playing around with this fantastic project. I am trying to do tests for AntBlazor. I already did couple of simple tests and they work great! I try now to do something that I somehow cannot figure out how to do.
I have this simplified component

@typeparam TItemValue
@typeparam TItem

<h1>test</h1>

@code {
    private IEnumerable<TItem> _datasource;
    [Parameter]
    public IEnumerable<TItem> DataSource
    {
        get => _datasource;
        set
        {
            _datasource = value;            
            if (AllowNotify)
                OnDataSourceChanged?.Invoke();
        }
    }
    [Parameter] public bool AllowNotify { get; set; } = true;
    [Parameter] public TItemValue Value { get; set; }
    [Parameter] public Action OnDataSourceChanged { get; set; }

}

And this test

@inherits TestContext
@code {
    record Person(int Id, string Name);
    List<Person> _persons = new List<Person>
    {
        new Person(1, "John"),
        new Person(2, "Lucy"),
    };

    [Fact]
    public async Task Action_fired_when_datasource_changed()
    {                
        bool handlerCalled = false;
        Action OnDataSourceChangedHandler = () => handlerCalled = true;

        var cut = Render<AntComponent<int, Person>>(
            @<AntComponent DataSource="@_persons"            
                Value="0"
                OnDataSourceChanged="OnDataSourceChangedHandler">
            </AntComponent>);

        _persons = new List<Person>();        
        Assert.True(handlerCalled);
    }
}  

What do I need to put in the test, that the AntComponent's DataSource setter will be fired before the assertion? I was trying to put something like this:

cut.WaitForState(() => object.ReferenceEquals(cut.Instance.DataSource, _persons));

but it did not work.
I can obviously do this

cut.Instance.DataSource = new List<Person>();

but I think this is not the right way (besides, VS warns me I should not access the property like this).
I was also trying with cut.Render(), but that did not help me either. I am obviously missing something...

[egil]

Hi @anddrzejb,

Interesting problem. I would suspect that

        bool handlerCalled = false;
        Action OnDataSourceChangedHandler = () => handlerCalled = true;

        var cut = Render<AntComponent<int, Person>>(
            @<AntComponent DataSource="@_persons"            
                Value="0"
                OnDataSourceChanged="OnDataSourceChangedHandler">
            </AntComponent>);

would call the setter of DataSource during SetParametersAsync like normal. If it didn't, then there is something fundamentally wrong with bUnit.

My best guess is that DataSource is set before OnDataSourceChanged, thus meaning property in the component OnDataSourceChanged is null when DataSource is set, causing it not to be fired. Setting parameters uses reflection, and it is likely to return the parameters in declaration order, meaning DataSource is set before OnDataSourceChanged.

If you want this functionality to work consistently, then you problably need to implement the setter logic inside either SetParametersAsync or in OnParameterSet.

If you want to verify this, you can always set breakpoints in your code and just debug your tests.

[egil]

Ps. to set components after the first render, use cut.SetParametersAndRender(...), that will cause the component to go through its normal life cycle when components are set.

[anddrzejb]

Thank you for your quick response!

You are generally correct in your assesment, but I think this is not the problem I am hunting.
So, when the component is initalized, indeed OnDataSourceChanged is not set. I am actually perfectly fine with that. What I want to tests is the fact that this line

_persons = new List<Person>();

should actually call DataSource setter (it is a new object after all). Then the setter should call OnDataSourceChanged action. Currently this is exactly what is happening when I test this component (well, not exactly this, here is just a simplified version) manually (I mean I startup my app in browser and with couple of Console.WriteLine() I can see it is called as I expect it).
I was debugging this first, to see how the order of events is happening. As you said, when Render<> is called, the DataSource setter is called. OnDataSourceChanged is still null. Then when I try to change the _person, the setter is not called at all. Only if I force it by calling cut.Instance.DataSource = new List<Person>();. That proves to me the OnDataSourceChanged is set before I request to change it. I did not mention that before, but I tried with cut.SetParametersAndRener(). I tried it before, after and even before & after _persons = new List<Person>()...

I can create a repro repo if you'd like me to.

[egil]

OK, I see.

Setting _persons = new List<Person>(); updates the variable _persons , not the property OnDataSourceChanged in the component, so this is completely expected. What you are actually doing is this:

var list1 = new List<Person>();
var list2 = list1;
list1 = new List<Person>();
Assert.NotEqual(list1, list2); // this passes.
Assert.Equal(list1, list2); // this fails

At this point, list2 will still point to the List<Person>() created in line 1, no the one created in line 3.

To probably set the DataSource in your component after the initial render, do the following:

cut.SetParametersAndRender(parameters => parameters.Add(p => p.DataSource, new List<Person>()));

This will cause the component under test to render again (2nd time), and have its SetParameterAsync method called with the new parameters passed to it. We have to use the parameter builder syntax for this for now. I have not come up with a way to make this work more intuitively with the the inline render fragment syntax.

See more here: https://bunit.dev/docs/interaction/trigger-renders.html#setparametersandrender

[anddrzejb]

Ok, it is clear. I am really glad nothing is fundamentally wrong with bUnit. It is an amazing piece of software.
I do hope a more intuitive solution is going to be available at some point, however this is completely sufficient. Thank you!

[egil]

@anddrzejb thanks.

If you think of something, let me know. But fundamentally it is pretty hard to do, as far as I can see, since how this works is related to how C# works, where references to variables are copied by default.

If we change that to passing references around instead copies of references, then we are likely getting into a bunch of compatibility issues with how Blazor works.