A testing library for Blazor components. Get started testing Blazor components at bunit.egilhansen.com/docs/getting-started/
Hey all - hoping someone is able to help out with an issue I'm having writing some tests. I have a cascading parameter that takes some services from DI. I'm trying to create tests for my child component and pass in the CascadingValue which from what I've read seems like it should be as simple as:
var cut = ctx.RenderComponent<Toast>(ComponentParameter.CreateCascadingValue("ParameterName", myValue)
In my situation here myValue is a `Mock<ParentComponent>' but whenever I debug the test the value is null so it's not picking it up
The easiest, if you dont want to think about it, is to use the builder pattern to pass parameters, e.g.:
ctx.RenderComponent<Toast>(ps => ps.Add(p => p.ParameterName, myValue));
is there a good working example of bUnit using Async web pages? I have a simple project which loads data base from database. when i test it with bUnit all is see is "loading"... and it is completing testing before data is loaded. so its a sync call. how can i make it async call... so bUnit waits for the page to completely load the data and then triggers test?
or a link to youtube video demoing the async funtionality for bUnit?
would like a working example and i will be able to figure it out from there
any such link available?
Its a common scenario. You can look at https://bunit.egilhansen.com/docs/interaction/awaiting-async-state.html and https://bunit.egilhansen.com/docs/verification/async-assertion.html for general input on handling async/delayed rendering of the component under test
Are you loading data from a real data source in your tests, or are you mocking your data source?
I think so, but I am not sure I exactly understand what you are trying to do.
bUnit doesnt look at the
@page directive in components though, so the navigation step will have to be manual.
That said, there is nothing preventing you from calling
var page1 = RenderCompoent<Page1>() and var page2 = RenderComponent<Page2>() in the same test class.
And you can pass in the same state to both components. You can even pre-register a cascading value that both should receive through the
TestContext.RenderTree, if that is how you share state.
Thanks for the feedback Egil. I was thinking about creating some BDD business test scenarios such as "When I want to pay out approved insurance claims, I first click on 'Pending Claims' in the application dashboard, then select the first approved claim listed then on the summary claim screen click the 'Issue Payment' button.". In a typical LOB Blazor app that scenario might traverse across 3 top level routable components. I gather from your first response that the Blazor navigation manager and location changed events are not hooked into the scope of a CUT?
But if you want to use navigation manager, you simply register one through the Services collection
I havent tried writing tests where the default blazor router is included, but that might work. you are certainly the first to ask though :)
I recommend starting with just testing individual components. Thats where bUnit execelles. But I am very interested in learning more about your scenario. Feel free to create a QA in the https://github.com/egil/bUnit/discussions. Its a much better place to share code samples and keep track of a discussion.
Is it possible to create a bunit test that checks for an expected UI update that should occur in response to a data update applied to a Fluxor state store? In this scenario I assume my Blazor component under test is bound to data in the Fluxor state store created as part of the test.
I dont see a problem with that. The only challange might be that the data arrives asynchronously, and thus you might need to use
cut.WaitForAssertion(() => /* assertion goes here */) since the test code runs in one thread and the component and renderer in another, to avoid deadlocks.
How is the Fluxor state store made available to the component?
According to the Fluxor docs the state store is injected as a private property. Yes I was anticipating the need to use cut.WaitForAssertion after reading your replies 13th Nov to @forex.ray.v1_gitlab and how to handle the delay when a unit test makes a live async remote request for data. Your recent presentation with Microsoft available on YouTube was very helpful particularly that bunit architectural slide, now I can picture where the threads run during a unit test.
but glad it helped
Is it injected with DI or is it a cascading value?
Eitherway, you will want a way to control that in your tests. If you can set the data in the store before your render your component, then its likely that the renderer will render the component synchronously and you wont need to use waitforxxx
control it, as have a way to set data in it.
Anyway, when you get it working, do post a sample in the discussions forum under the show and tell category. Will likely be very useful to others.
[Inject]
private IState<CounterState> CounterState { get; set; } https://github.com/mrpmorris/Fluxor/blob/master/Tutorials/02-Blazor/02A-StateActionsReducersTutorial/README.md
Anyway, it does seem like you can just mock or even better, create fake of
IState, and then in your test, write Services.AddSingleton<IState<CounterState>>(new FakeState(....))
PS: @camelCaseSharp -> https://gitter.im/mrpmorris/fluxor
If you are interested
Hi Egil. I'm writing some tests and running into an issue with context menus. Our solution is using a nuget package (Blazor.ContextMenu v.1.8.0) for context menus in our app. It seems like they may be using the HTML 'oncontextmenu' event rather than the blazor '@oncontextmenu' event, would that make it so that the Element.ContextMenu() call in BUnit can't find the event?