-
-
Notifications
You must be signed in to change notification settings - Fork 115
Description
Analyzer package
We could invest some time to tackle some common issues users might face (or antipatterns) with our own analyzer. If we have a look into the issue tracker, we see this example a few times:
The render handle is not yet assigned.
Users might define a razor file with bunit like this:
@code
{
[Fact]
public void Test()
{
using var ctx = new BunitContext();
Action<MouseEventArgs> onClickHandler = _ => { Assert.True(true); };
var cut = ctx.Render(@<EventCallbackParams
OnClick="onClickHandler" />);
cut.Find("button").Click();
}
}This fails with
"System.InvalidOperationException : The render handle is not yet assigned."
Because the razor component isn't part of the RenderTree of the Blazor Renderer. So everytime we have a callback or variable (also two-way bindings) in razor syntax it might fail.
Therefore the fix is to do
@inherits BunitContext
@code
{
[Fact]
public async Task Test()
{
var wasInvoked = false;
Action<MouseEventArgs> onClick = _ => { wasInvoked = true; };
var cut = Render(@<EventCallbackParams OnClick="onClick" />);
var button = cut.Find("button");
await button.ClickAsync(new MouseEventArgs());
cut.WaitForAssertion(() => Assert.True(wasInvoked));
}
}Here we can easily help the user that if he uses a .razor file and has some variables passed from the test bi-directional (or events) to the cut, the user should use @inherits BunitContext.
Another one might be (in any variation):
IHtmlAnchorElement elem = (IHtmlAnchorElement)cut.Find("cssSelector");
// Could be
var elem = cut.Find<IHtmlAnchorElement>("cssSelector");We probably could find more examples.
Risks
- The biggest risk I see is our time. Maintaining that might be an additional burden.
Additional
- We need to add also some documentation in our
docs/directory so people know what the Analyzer is and does. - We might want to promote this in the README.md (link to the nuget package - once it is available)