Stubbing of child elements, which are used with @ref

[DrMueller]

We have a complex component, which uses a lot of JavaScript under the hood (an open layers map abstraction) and a layer of components, which use this base open layers component, applying business logic to it.

Due to the complexity, working just with bindings didn't work out, so we're exposing the element reference in the code behind and the component offers some methods. For example:

<Map
    @ref="@Map"
              SelectionIsAllowed="true"
              OnAreaClicked="HandleAreaClickedAsync" />

and in the code behind, exposing it:

private Map Map { get; set; } = null!;
...
await Map.DeactivateDrawingAsync();

This couples the components heavily, but we couldn't come up with a better solution here.
Anyway, generally, it is working out fine, but it doesn't seem to be possible to mock the Map reference with Bunit? What we tried so far:

Direct stub

this.ComponentFactories.AddStub<Map>();

This doesn't work, as the stub can't be cast, resulting in:

System.InvalidCastException : Unable to cast object of type 'Bunit.TestDoubles.Stub`1[Map]' to type 'Map'.

Interfacing of the reference

As Blazor can fill the reference with an interface, I've interfaces the component out:

private IMap Map { get; set; } = null!;
...
await IMap.DeactivateDrawingAsync();

This is generally a bit better, as it decouples at least the code behind, but it seems like BUnit then can't bind it:

this.ComponentFactories.AddStub<Map>();
this.ComponentFactories.AddStub<IMap>();
this.ComponentFactories.Add<IMap>(Mock.Of<IMap>());

Is there therefore any possibility to have unit tests, when using child-components with the @ref keyword? Or are there other approaches we could use to have some possibilities for automated tests?

[linkdotnet]

Hey,

that is an interesting problem. Our Stubs do just mimic the public API, rather than implementing the class itself.

That said you could use Add with a custom implementation: https://bunit.dev/api/Bunit.ComponentFactoryCollectionExtensions.html#Bunit_ComponentFactoryCollectionExtensions_Add__2_Bunit_ComponentFactoryCollection_

and basically mimicking the public api yourself and really inheriting from your Map type.
That means that you may Wanna make same calls virtual.

[linkdotnet]

Hi Steven, thank you for the feedback. Just out of interest, is my way of implementing complex behavior generally wrong, using @ref? I didn't find another solution, as just using bindings didn't cut it, but that would mean, none of the components used this way are unit-testable with BUnit.

That is difficult to say - it works for you, so that already checks some marks for "into the right direction".
The obvious other candidates would be two-way binding, refactoring into services and so on. But difficult to say without having a whole lot of context.

Regarding the custom factory, are you sure this should work? Probably I didn't explain it well enough: I would like to test a component using the Map-component, but having the Map-component kinda-how stubbed out. So, for example we have a FieldMap-component, which then uses the Map-component.

So the Map-component is a some kind of wrapper? Maybe can you give an (over)simplified example of the test you would like to write.

The factory would be something like:

public class MapFake : Map
{
    public override Task DeactivateDrawingAsync()
    {
        // Trigger something without any Javascript for your test case
    }
}

// In your test
[Fact]
public async Task MyTest()
{
    ComponentFactories.Add<Map, MapFake>();
    // Setup code ....
    var mapFake = cut.FindComponent<MapFake>();
    await cut.InvokAsync(async () => await mapFake.DeactivateDrawingAsync());

But that depends on what you want to achieve and what your test setup looks like.

[DrMueller]

@linkdotnet Hi Steven, I've created a small repo to tinker around, what I would like to achieve: https://github.com/DrMueller/BunitBlazorTesting.

Revisiting the BUnit.Dev documentation, you also have a chapter about mocking with MOQ https://bunit.dev/docs/providing-input/substituting-components.html?tabs=moq. But you're using the implementation type directly. This is in my opinion not very feasible, as you would then need to define productive code as virtual, which isn't that good of a practice in my opinion?
But, thinking of it, we always have a hard coupling between components, at least on the razor ui, as we're setting the components directly. Therefore, it might generally not be possible to do what I'd like to do.

The only way I'd see this working is, that BUnit would check the target type for @ref and cast the instance to this target type. As the compiler checks between the component and the @ref, this would always be valid. But I have no idea how BUnit is set up 😸 .

[linkdotnet]

But you're using the implementation type directly.

There isn't any abstraction around your component. The described approach isn't valid in every scenario.
Most of the times you might be better off to provide your own fake version, that gets replaced via the. Add<TComponent, TStubComponent>() - unfortunately that doesn't help in your scenario.

I will have a look at your repro these days. THanks for offering that!

[linkdotnet]

@DrMueller

Here a bit more contxt, if you can spare a few minutes: https://youtu.be/tWfBXPRnf-M?t=571

[DrMueller]

@linkdotnet Hi Steven, thank you for discussing the topic so thoroughly with Egil. Easiest solutions according to you are:

• Define methods as virtual -> Mockable with MoQ or custom fake-implementations afterwards
• Create proxy services, which operate on the passed @ref, making these service-operations mockable again
• Don't do shallow-testing, but use the direct sub-components, mock just the javascript calls

The only interesting point left for me is: When using Blazor normally via debugging, the "@ref as interface" trick works fine, but it doesn't work with BUnit. Are you kinda-how interfering with the @ref logic directly or is this just a side-effect of the BUnit implementation?

Anyway, the topic is closed for me, thank you again very much for your efforts.