Support request app has a nice feature (powered by the echarts gadget) that clicking on a series on the graph will filter the corresponding listbox to display all the supports requests from this series.

This was not covered by functional test and this is what this merge request is addressing.

Selenium comes with a clickAt ( locator,coordString ) API which is a "beautiful" way of simulating a click somewhere in the screen, so we could use this to simulate a click.

Problem is that we need to wait for chart to be displayed. The first step was just to wait for the canvas element to be in the DOM, this was enough for the bar chart, but not for the pie chart, because there is an animation and we need for the animation to stop, otherwise we might click before the series is completely and when we click, the animation is still running and we don't click on the series because it's still being animated:

Good news is that echarts fires a finished event we can wait for, but for that we had to update echarts version to 4.1.0 . This was exposed on the chart gadget as a disabled attribute - the element initially has a disabled attribute and attribute is removed when ready to inspect in tests. I think this is the way we do in other gadgets.

After updating echarts, the way of simulating click by clickAt stopped working, this new version of echarts only understand clicks that comes after a mousedown event, so the test needs to mousedown and then click.

Where it gets really complicated, is the click must be given in pixel position on the chart canvas and the layout varies a bit depending on the size of the canvas, which itself depends on the browser window size. For this we calculate the click position based on a percentage of the canvas size (there are some ascii art explaining this in the test html). I was also considering to make the chart gadget listen to a custom test.clickSeries event with the same name and seriesName properties that are used in the chartItemClick method and have selenium dispatch such an event (in a assertEval or another selenium statement where we can write raw javascript). This test is still too fragile in my opinion - I'm still adjusting it for various screen sizes and I'm not sure it passes on testnodes. On the other hand, we could hardcode a firefox window size in our test suite.