A testing library for Blazor components. Get started testing Blazor components at bunit.egilhansen.com/docs/getting-started/
Anyway, to answer your question, you can always call
cut.Render() or cut.SetParametersAndRender(...) if you need to pass new parameters.
Here is the relevant doc: https://bunit.egilhansen.com/docs/interaction/trigger-renders.html
That will return a IRenderedComponent<TComponent>
Running into some behavior I don't understand. I have a Page component. The Page has a Form component. The Form has controls on it. I am asserting on the contents of the form. I have one particular test where the contents of the form controls are not what I'm expecting. When I examine the markup of the Page, the contents are exactly what I expect to see. But when I examine the contents of the form IRenderFragment, retrieved with _RenderedPage.FindComponent<Form>(), they are different, containing values that were set previously in the test but that were subsequently cleared out.
What could be going on here? Is there some need to refresh something? Is there some race condition?
Hi @demonsweatlive, not sure without seeing any code, but it could be a race condition. For that, you might need this: https://bunit.egilhansen.com/docs/verification/async-assertion.html
There is also this method: https://bunit.egilhansen.com/docs/interaction/awaiting-async-state.html
IRenderedComponent<Page> _RenderedPage = context.RenderComponent<Page>(); // initialised early in test//in assertion phase
var markup = _RenderedPage.Markup; //<-------- This markup has exactly what I expect for the Form component.
var form = _RenderedPage.FindComponent<Form>();
var formMarkup = form.Markup; // <---------- This markup is different. It has outdated values
How can they be different?
I have to run pick up the kids, but if you can create a minimal example that reproduces this issue and share it in the github repo through an issue, that would be great.
From what you are telling me it should not be different.
Very difficult to understand what it is about this particular test that could be causing this.
The governor of (Texas?) told him that he expected to lose his seat but was re-elected, and Trump is more popular than him so there is no way Trump could have lost
This guy ran a country?
@mrpmorris its impressive indeed. But thankfully he needs to convince the courts, and so far that has not been going great.
@egil I'm not sure it's doable, given the massive size of the code base, and paring it down to bare essentials doesn't feel like it would be worth the effort, at this point. I do recall running into an error reminiscent of this, so I'm just going to plow forward and hope I can figure it out eventually. If not, then I'll circle back around. I was just hoping there was something obvious that I was missing. There's a chance that it could have to do with async state, so I'll focus on that.
@demonsweatlive thats fair. Just to recap, this is the basis of what you are seeing:
- Render component Foo which has subcomponent Bar.
- Do something to cause component Bar to rerender and have changes in its markup
- Be able to view the markup changes of component Bar through parent component Foo.Markup AND NOT be able to see the changes in Bar.Markup.
Does that sum it up?
If so, I am very curious to hear what learn what you are doing in step 2.
@egil The entire page is a component, with subcomponents of grid and form. If I edit something on the form, then click on different grid item, I'm prompted by a modal as to whether I want to discard the changes, save the changes, or cancel switching to the new user.
My test is doing that, choosing to "Discard" the changes, then clicking on another grid item (which does a server fetch), and then back to the original grid item (another fetch) in order to make sure that nothing was modified.
However, I'm asserting on the Form sub-component, and there, the values are different. There items that I entered previously that should have been discarded. As though nothing in that sub-component changes after some point.
This happens whether I have a reference to the rendered Form saved from the beginning of the test, which works everywhere else and for every test; or whether I FindComponent<Form>() from the rendered Page at assert time.
It's as though something is internally caching that form and giving me an older state
It's as though something is internally caching that form and giving me an older state
There is a single RenderTree that is updated when a component renders. But what can happen is that your changes are happening asynchronously... put differently, the blazor renderer that is updating the render tree is updating it in a different thread than the one the test is running in, so the changes might be coming, but might not be there yet. The problem you are seeing might be due to beta-10 though. There was some changes to have the render tree updates would update the markup in the components, and you might be seeing a corner case I believe is fixed now.
@egil Not worried about the API change, easy enough. I mean that after the code changes, many of the tests were now failing.
OK. That surprises me. Are you saying tests that use something like await cut.Find("button").ClickAsync() now fails with cut.Find("button").Click()?
Yes. As I mentioned, I have several hundred tests now, so I don't know exactly what was failing, or why, or what code paths were traversed. Being so frustrated with this single test, I just couldn't bring myself to start digging as to what would cause dozens more to fail after making those changes, and immediately downgraded.
!