WaitForState() unconsistent behavior

[anddrzejb]

I continue my tests of AntBlazor and I was writing tests for the Form component. I had some issues there, but eventually I solved them. Based on the Form, I decided I am going to make also test for Input component. It seemed to me it should be obvious, because my Input tests were going to be just a simplified earlier Form tests, but unfortunately, that is not the case.

So first I will show the test for the Form (that is working properly, its purpose is to check if EventHandler is properly wrapped in EventCallback):

@inherits AntDesignTestBase
@code {

	class Model
	{
		public string Name { get; set; }
	}
	Model _model = new();
	AntDesign.Form<Model> _form;

	[Fact]
	public void Form_EditContext_fires_OnFieldChange()
	{
		//Arrange
		bool handlerExecuted = false;
		Action<FieldChangedEventArgs> onFieldChanged = (e) => handlerExecuted = true;
		var cut = Render<AntDesign.Form<Model>>(
			@<AntDesign.Form @ref="@_form" Model="@_model"
				OnFieldChanged="onFieldChanged"
				ValidateOnChange="@true">
				<AntDesign.FormItem Label="Name">
					<AntDesign.Input @bind-Value=@context.Name/>
				</AntDesign.FormItem>    
			</AntDesign.Form>
			);		
		var input = cut.FindComponent<AntDesign.Input<string>>();  //<= getting the Input component to manipulate it directly
		//Act
		input.Find("input").Input("newValue");
		input.Find("input").KeyUp(String.Empty); 
		//Assert		
		input.WaitForState(() => input.Instance.Value is not null);
		handlerExecuted.Should().BeTrue();
	}
}

A bit of introduction is needed here - I cannot just use input.Change("newValue"), because the value is not changed then. Due to the debounce implementation, the change is actually performed as a sequence of OnInput and OnKeyUp events. The value passed to OnKeyUp is not really important, the saved value in OnInput is used. But the Value is changed in OnKeyUp. That is why there are 2 calls in the input component. Because debounce is set by default to 250ms, so the Value should be updated after 250ms of inactivity - that is why I used there WaitForState().
Normally, for the test purposes I will get rid of debounce, so the tests can run faster.
As I wrote eralier, I figured I can use this test to also test the AntDesign.Input component (it actually is used in the Form test).

So, I created this:

@inherits AntDesignTestBase
@code {
	[Fact]
	public void Input_Debounce_sets_value()
	{
		//Arrange
		string value = null;
		var cut = Render<AntDesign.Input<string>>(@<AntDesign.Input @bind-Value=@value/>);
		//Act
		cut.Find("input").Input("newValue");
		cut.Find("input").KeyUp(String.Empty);
		//Assert
		cut.WaitForState(() => cut.Instance.Value is not null);
		cut.Instance.Value.Should().Be("newValue");
	} 
}

To my surprise, I got this error

Message: 
    Bunit.Extensions.WaitForHelpers.WaitForFailedException : The state predicate did not pass before the timeout period passed.
  Stack Trace: 
    RenderedFragmentWaitForHelperExtensions.WaitForState(IRenderedFragmentBase renderedFragment, Func`1 statePredicate, Nullable`1 timeout) line 29
    --- End of stack trace from previous location ---
    RenderedFragmentWaitForHelperExtensions.WaitForState(IRenderedFragmentBase renderedFragment, Func`1 statePredicate, Nullable`1 timeout) line 39
    InputTests.Input_Debounce_sets_value() line 14

I run the debugger. I see that the Value parameter is changed during WaitForState(). I tried adding more time to cut.WaitForState(() => cut.Instance.Value is not null, TimeSpan.FromSeconds(3)); but not different. It is like the cut.Instance is not in the sync context? I also tried with cut.WaitForAssertions() which is actually my preferred method here (no need to run the next assertion), but, as well, no success there either.

[egil]

Hi @anddrzejb,

A few questions:

1. What version of bUnit and .net are you using?
2. Is the difference between the two tests that in one test, the AntDesign.Input<string> is a child component of AntDesign.Form<Model> and in the other test, it is the main component under test?
3. Does the Input_Debounce_sets_value fail consistently every time you run it, or is it random?

[anddrzejb]

1. No, I actually started playing around with bUnit when you removed them (I wasn't waiting for removal, just happened like that). I cannot find any references to Fixture or SnapshotTests in the tests that were in before I started playing around.

I was afraid you are going to ask me for a minimal repro, because it would be really hard to make it (given the project's structure), so you asking me for a branch is a godsend 🙇🏻 . My branch that I currently work on is here. During the tests I comment out all gulp tasks (in .components/AntDesign.cproj lines 70 & 74-75). I do not think you need to uncomment them, because it only compiles .ts & .less files. If you find you need them then the build time may take some time.
The test project is in .components/tests/AntDesign.Tests. The 2 tests in question are located here:

• Form: .components/tests/AntDesign.Tests/Form/EditContext/Form.EditContext.BuildTests.razor
• Input: .components/tests/AntDesign.Tests/Input/InputTests.razor

Thank you very much for the time you are willing to spend on this.

[egil]

1. In that case, simply remove bunit.xunit.

Your typescript/JavaScript should not have influence on the tests, since bunit runs only in c#.

I'll take a look, perhaps later today during my regular twitch.tv/egilhansen stream.

[anddrzejb]

1. The branch already have the nugget removed. I also run tests after I removed the package and all of them (except the Input one) are passing, so we are ok there.

Great. I will try to attend, if kids allow...

[egil]

We looked at this together on https://www.twitch.tv/videos/1017736669 today.

The conclusion was that the reason WaitForState never passes (times out) is because the component actually never renders when the timer fires and causes the Value property to be changed. Unfortunately, the only way around this is to either cause the component to re-render by calling StateHasChanged in the component after the timer fires, or wait in a different way, e.g. through Task.Delay.

[anddrzejb]

@egil Thank you very much for the attention you gave to my problem. As I promised, I will try to add this case to documentation, hopefully with some kind of minimal repro. You're awesome!