A testing library for Blazor components. Get started testing Blazor components at bunit.egilhansen.com/docs/getting-started/
Here is an example of a test that does this: https://github.com/egil/blazor-workshop/blob/master/save-points/09-progressive-web-app/BlazingPizza.Tests/Client/Pages/CheckoutTests.razor#L59-L74
Then you just need to register it with the TestSontext's services collection, e.g.:
ctx.Services.AddSingleton<NavigationManager, FakeNavigationManager>()
@egil Thanks for your reply! Ya, I already implemented something like this, I found an old thread where you discussed this with someone and they provided their fake navigator there. Sorry, I should've said this so you wouldn't spend time on that! But ok, then I know the scope of this kind of test :)
Still nice to see that page with all those tests, I might use it to find other answers later on ^^
there is a whole series of videos of me building all the tests you see in that blazor-workshop repo: https://www.youtube.com/channel/UCcHRuajIkdHagmpdkE01YPg
if you want to learn more.
ahh this is probably the playlist you want: https://www.youtube.com/playlist?list=PL2LoDmbC1g20uJjUwPGQxpQjdnmpMqV0t
I think i may have got it to work by just copying this code and reapplying it for the
https://github.com/egil/bUnit/blob/74fd44bf548417bfb75971d498a996816387904f/src/bunit.web/TestDoubles/Authorization/FakeAuthorizationExtensions.cs#L16
Fixture type. Not sure if that is the cleanest solution though.https://github.com/egil/bUnit/blob/74fd44bf548417bfb75971d498a996816387904f/src/bunit.web/TestDoubles/Authorization/FakeAuthorizationExtensions.cs#L16
A
Fixture is a TestContextBase.
@thepigeonfighter yeah, its not super obvious nor well documented, so I think you are excused. Another feature I need to document is an new approach to writing tests in razor components. You can see examples of this in this sample's tests project: https://github.com/egil/blazor-workshop.
One more issue I just ran into is when using an
EditForm component with a button as a child element the EditForm get triggered by clicking on that button. But if I try to do a "Click" via bUnit it says there is no click handler registered, which makes sense. But not sure how to submit the form via bUnit's api?
Glad you figured it out.
I am developing an Blazor HTML5 canvas application. I am getting a lot working so that isn't the issue. What I am trying to figure out is how to test the Canvas code. I was thinking to capture a bitmap then test comparing the output of the canvas to check for regression. Using like Selenium in xUnit or bUnit? I am looking for ideas...
@bfmsoft isn't the problem that bUnit doesn't run JavaScript, and canvas is entirely driven by JavaScript?
With bUnit, the only thing you can do is have it record the JavaScript invocations and assert against those. Not sure the value of that kinda test though.
So I've ran into an issue trying to follow the new razor testing patterns put forth in https://github.com/egil/blazor-workshop. the following code results in some unexpected results. When I inspect the values after these "change" calls the first "change" call appears to not be setting the value in the component's markup. I suspect it has something to do with the component not being completely rendered?
var cut = Render(@<ManageUser ConfirmPasswordChange="DummyActions.AlwaysTrueFunc"
OnPasswordUpdate="DummyActions.OnEvent"></ManageUser>);
cut.Find("#new-password").Change("Test123!");
cut.Find("#new-password-confirm").Change("Test123!");
cut.Find("#old-password").Change("Admin123!");
For context the ManageUser component uses
OnInitializeAsync. I have switched the order of these find statements and whatever the order the first of the three calls is null in the rendered markup while the other have expected values.
hi @thepigeonfighter, that has nothing todo with the new razor testing pattern. If you have some async code in a component life cycle method, is is like, as you say, that it is because the component has not finished rendering when you start issuing your Find and Change calls. You likely need https://bunit.egilhansen.com/docs/interaction/awaiting-async-state.html or https://bunit.egilhansen.com/docs/verification/async-assertion.html to help you.
@thepigeonfighter hmm, no that is really the thing you are looking, the output from the component. however, if your component has a property that is set when it is done rendering, e.g.
MyCompoent.ImDoneNow, then you can also inspect that. E.g. cut.WaitForState(() => cut.Instance.ImDoneNow);
I would also recommend that you assert on expected output, since that will make your tests more stable. I am planning to add a
For now, I would do
WaitForElement/WaitForElements that will make it a little less verbose.For now, I would do
cut.WaitForState(() => cut.FindAll("elementSelector").Count == 1)
Actually in my use case it was finding the input element. It just wasn't setting the value of the input. If that makes sense. Looking at how the page loads naively I'd guess that the input tag gets rendered and then the value set by blazor's javascript? Not sure how long the delay between those two events are. So in my particular case I'm not sure waiting until i could find the element would do the trick?
I have one "bug" that might be related to what you are seeing: egil/bUnit#46
