Handling a click event at the location of a child element

[danielchalmers]

In the tests for an analog time picker we had an @onclick on every stick so the tests were written like this:

// Select 30 minutes
comp.FindAll("div.mud-minute")[30].Click();
picker.TimeIntermediate.Value.Minutes.Should().Be(30);

But the click event has been removed from the stick and replaced by pointerdown/pointerup on the parent which then uses event.target to get the value stored in the stick's attribute (+This has been moved to JavasScript).

What's the canonical way to trigger a pointer event on a higher element at the exact location of the mud-minute? Trying to keep it simple as there's dozens of tests like this.

[linkdotnet]

Hey @danielchalmers,

just to get a better picture of the whole situation: We are talking about testing inside MudBlazor itself and not MudBlazor as a 3rd party component?

So the new functionality behaves as such:

• I, as a user, click on the "minute" part (for example 30 - see example below)
• The element bubbles up to the parent, which catches the event (JavaScript) and calculates based on event.target where the event originates

Did I get this right?

In general, events that bubble in the browser will also bubble with bUnit. Unfortunately, this will help you only to a certain degree if the logic is contained in JavaScript, which will not be executed here. Before jumping to any conclusions from my side, can you draw a picture of how the current setup is?

[danielchalmers]

Thanks! So as of MudBlazor/MudBlazor#9300 the only events are on the clock-level in JS and it will use event.target to find the minute/hour element (which contains a data attribute of the value) under the pointer when you click somewhere on the clock. There are no events on the minutes/hours themselves and there are no events registered in C#. It works well but I'm just lost on how to update the tests.

[linkdotnet]

That is a very good question. Given the more "integration" nature of the test, I'm leaning towards the fact that using bUnit for that specific instance doesn't help you much.

Whatever you do (as you emulate and set up all JS interop) will most likely result in testing the test code (your JS Mock setup).
The obvious candidate would be something like Playwright/Cypress/... but that would be an entire new approach as far as I could see in MudBlazor's codebase.

Another approach might be to introduce an humble object that does the JS interop:

public interface IClockJsInterop
{
    Task<int> GetStickValueAsync(ElementReference clockElement, double clientX, double clientY);
}

Which you could set:

var jsInteropMock = CreateIClockJsInteropMock();
jsInteropMock.Setup(js => js.GetStickValueAsync(It.IsAny<ElementReference>(), It.IsAny<double>(), It.IsAny<double>()))
                 .ReturnsAsync(30);