You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
.NET5 will bring 1st party components with Blazor that uses JSInterop, and bUnit should support those out of the box (e.g. the Virtualize component). That means providing default planned invocations registered in the mock jsruntime in bUnit for those components.
That requirements leads naturally to an "on by default" or "always on" JSInterop in bUnit, where instead of having to call Services.AddMockJSRuntime(), bUnit's mock jsruntime is registered by default in strict mode. Strict mode is important in this case, as that will make it work much like the current setup, where users custom JSInterop logic is not mocked unless explicitly done so, or if the mock is put in to loose mode.
The MockJSRuntimeInvokeHandler will then be available through a property on the TestContext type, i.e. MockJSRuntimeInvokeHandler JSInterop { get; }, where Mode going forward should be settable.
For backwards compatibility, the existing AddMockJSRuntime() can be marked as obsolete.
And if users want to use their own IJSRuntime and register that through a call to Services.Add****<IJSRuntime>(...) methods, then the builtin bUnit mock will simply be replaced and all will continue to work for those users.
Adding the JSInterop property will also make it easier and cleaner for 3rd party component vendors who want to support testing with bUnit of their components. They can provide an extension method to TestContext that registers handlers for their JS modules/functions, as well as adding any context components to the base render tree (#155). That should allow for a very seamless experience for their users.
RELATED
Add "planned invocations" for built-in types in Blazor.
.NET5 will bring 1st party components with Blazor that uses JSInterop, and bUnit should support those out of the box (e.g. the
Virtualize
component). That means providing default planned invocations registered in the mock jsruntime in bUnit for those components.That requirements leads naturally to an "on by default" or "always on" JSInterop in bUnit, where instead of having to call
Services.AddMockJSRuntime()
, bUnit's mock jsruntime is registered by default in strict mode. Strict mode is important in this case, as that will make it work much like the current setup, where users custom JSInterop logic is not mocked unless explicitly done so, or if the mock is put in to loose mode.The
MockJSRuntimeInvokeHandler
will then be available through a property on theTestContext
type, i.e.MockJSRuntimeInvokeHandler JSInterop { get; }
, whereMode
going forward should be settable.For backwards compatibility, the existing
AddMockJSRuntime()
can be marked as obsolete.And if users want to use their own
IJSRuntime
and register that through a call toServices.Add****<IJSRuntime>(...)
methods, then the builtin bUnit mock will simply be replaced and all will continue to work for those users.Adding the
JSInterop
property will also make it easier and cleaner for 3rd party component vendors who want to support testing with bUnit of their components. They can provide an extension method toTestContext
that registers handlers for their JS modules/functions, as well as adding any context components to the base render tree (#155). That should allow for a very seamless experience for their users.RELATED
Add "planned invocations" for built-in types in Blazor.
The text was updated successfully, but these errors were encountered: