WaitForState Predicate Execution Semantic - Execute

[groogiam]

The WaitForState method currently only executes the predicate on the initial call and for each re-render. As this deals with internal state having the check only be tied to the rendering does not seem correct. I have several places in my tests that have WaitForState that will randomly fail because the state change does not explicitly trigger a Re-Render. See #811
For example property changed hooks may trigger and update to state that is not directly rendered but would effect future operations the user takes. To work around this I currently have to force a re-render in my client logic which often is just wasted cpu cycles or add Task.Delays to my tests. I think both of these could be avoided by having the WaitForState perform the predicate check one last time after the timeout has elapsed. Thoughts?

[linkdotnet]

Hey @groogiam

I do understand your reasoning, but I am not sure if "a last check" would help you in the big picture - especially from a library point of view. First, a timeout is a hard border where everything after is no longer important. Like if you call a database and it times out after 30 seconds, should the driver check one last time if the results are ready?

Secondly, doing a last check would mean the same as: Just increase the timeout by 0.1 seconds, and you are good to go, but that will not help you either I guess.

Now a bit of personal flavor here: Testing your component should ideally anyway rely on observable things rather than the internal state. In your concrete example, you talked about how the action itself doesn't have an observable impact but will have implications on the following actions. Wouldn't that be your gateway for a successful test?

to state that is not directly rendered but would effect future operations the user takes

How would the user know that in your example? Why does he do something else if there is no indication for the user?

[groogiam]

In the cases I'm encountering the internal state is actually passed to a sub component. So checking it from the user interface side ends up verify markup on a sub component that is already covered under other unit tests. Not only does this make the test significantly more complicated it muddies the water of what is actually under test. In my case the thing that actually needs to be validated is that the internal state was in fact set to a specific values as we would assume that the handling of them would be adequately covered by the sub component unit tests. As they do not immediately display on the UI or logic does not trigger a StateHasChanged which causes the tests to fail.

I can understand your and @egil point about wanting to keep the inbuilt WaitForX focused on the rendering. The proposed solution of rolling my own assertion extensions seems like a reasonable approach. I just wanted to have a discussion to see if this something that some more generalized wait logic would have been beneficial in the library. Based on your responses it sounds like doing so could create confusion on which WaitFor methods to use if they were added. I'll move forward with creating my own extensions. Thanks for taking the time to discuss.

[egil]

@groogiam sounds good. If your goal is isolating the component under test, you can also look at substituting out child components with stubs/mocks during testing: https://bunit.dev/docs/providing-input/substituting-components.html

[egil]

Hey @groogiam,

I'll just add my 2 cents here too.

All the WaitForX methods are explicitly added to bUnit to allow you to try and assertion after a render, because we know when a render has happened. However, I do recognize the use case you are talking about, I actually had something similar at work recently, so there I created these custom extensions methods in the fluent assertion language, that allows me to retry an assertion every N ms until a timeout is reached.

namespace FluentAssertions;

public static class ShouldAsyncExtensions
{
    public static async Task<TAssertion> ShouldAsync<T, TAssertion>(this T subject, Func<T, TAssertion> assertion, TimeSpan? timeout = null)
    {
        var testTime = timeout ?? TimeSpan.FromSeconds(1);
        Stopwatch? timer = null;
        while (true)
        {
            try
            {
                return assertion(subject);
            }
            catch
            {
                timer = timer ?? Stopwatch.StartNew();

                if (timer.Elapsed > testTime)
                {
                    throw;
                }

                await Task.Delay(10);
            }
        }
    }

    public static async Task ShouldAsync<T>(this T subject, Action<T> assertion, TimeSpan? timeout = null)
    {
        var testTime = timeout ?? TimeSpan.FromSeconds(1);
        Stopwatch? timer = null;
        while (true)
        {
            try
            {
                assertion(subject);
                return;
            }
            catch
            {
                timer = timer ?? Stopwatch.StartNew();

                if (timer.Elapsed > testTime)
                {
                    throw;
                }

                await Task.Delay(10);
            }
        }
    }
}

They basically allow you to do something like this:

await cut.ShouldAsync(cut=> cut.Instance.MyProp.Should().Be("Foo"));

We do not want to add generalized assertion cases into bUnit if we can avoid it though, but you can create your own overloads that combine ours with something that is general to your assertion framework like I did above.