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.
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.
\nWhatever you do (as you emulate and set up all JS interop) will most likely result in testing the test code (your JS Mock setup).
\nThe 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:
\npublic interface IClockJsInterop\n{\n Task<int> GetStickValueAsync(ElementReference clockElement, double clientX, double clientY);\n}Which you could set:
\nvar jsInteropMock = CreateIClockJsInteropMock();\njsInteropMock.Setup(js => js.GetStickValueAsync(It.IsAny<ElementReference>(), It.IsAny<double>(), It.IsAny<double>()))\n .ReturnsAsync(30);Handling a click event at the location of a child element #1497
-
|
In the tests for an analog time picker we had an // Select 30 minutes
comp.FindAll("div.mud-minute")[30].Click();
picker.TimeIntermediate.Value.Minutes.Should().Be(30);But the What's the canonical way to trigger a pointer event on a higher element at the exact location of the |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
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:
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? 
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks! So as of MudBlazor/MudBlazor#9300 the only events are on the clock-level in JS and it will use |
Beta Was this translation helpful? Give feedback.
-
|
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). 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); |
Beta Was this translation helpful? Give feedback.
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:
Which you could set:
…