search

bUnit-dev / bUnit

bUnit is a testing library for Blazor components that make tests look, feel, and runs like regular unit tests. bUnit makes it easy to render and control a component under test’s life-cycle, pass parameter and inject services into it, trigger event handlers, and verify the rendered markup from the component using a built-in semantic HTML comparer.
https://bunit.dev
MIT License
1.16k stars 109 forks source link

`IJSInProcessObjectReference` can't be imported with `SetupModule` #484

Open KristofferStrube opened 3 years ago

KristofferStrube commented 3 years ago

Is the feature request related to a problem? Please elaborate.

The SetupModule extension for setting up an imported JS module only supports IJSObjectReference but you can also import modules of types IJSInProcessObjectReference and IJSUnmarshalledObjectReference.

The suggested solution

IJSInProcessObjectReference and IJSUnmarshalledObjectReference are derived from IJSObjectReference so I think it should be possible to support this with minor changes.

Describe any alternative solutions

If we can not use that they are derived interfaces to IJSObjectReference then it could just be implemented like the module setup feature for IJSObjectReference.

Additional context

I don't think a lot of people use this way of importing modules so might not be a priority.

Currently, I just do the following instead:

TestContext.JSInterop.Setup<IJSInProcessObjectReference>("import", "./_content/MyPath/MyFile.js");

Might also be related to the last bit in this old issue #233 where we quickly mentioned IJSInProcessObjectReference

egil commented 3 years ago

Hi @KristofferStrube

The problem is that you cannot overload based on generic types, so it would mean making SetupModule generic, e.g.: SetupModule<TObjectReference>(...) where TObjectReference : IJSObjectReference to keep using the same name (SetupModule). But that will require users to always specify the IJSObjectReference or a derived type, even in the most common case, e.g. SetupModule<IJSObjectReference>(...).

As you say, its probably not too many that needs this, so I would like to keep things simple for the majority. If your workaround works, then I think I will keep it as is, and instead document this particular use case.

What do you think?

KristofferStrube commented 3 years ago

Hey @egil

I think you are right. Let's just keep it as it is and maybe document it in this section: https://bunit.dev/docs/test-doubles/emulating-ijsruntime.html#support-for-ijsinprocessobjectreference-and-ijsunmarshalledobjectreference

egil commented 3 years ago

Ill add it to the to-do list. If you want, a docs PR is very welcome ;)