Broken Selenium test with new radio/checkbox styles

Question

Broken Selenium test with new radio/checkbox styles

Closed this issue 7 years ago · 8 comments

We've spent 2 days trying to figure out why our Selenium tests suddenly stopped working when updating to the new radio/checkbox styles.

I thought I'd open this issue to potentially save others with the same problem, and hopefully discuss what the best solution is.

Previously the test looked for input elements with a specific ID in order to click them. The new styles are physically hiding the input element (with opacity) in favour of the pseudo checkbox/radio control, and this prevents the Selenium tests from being able to click them. We are currently looking at the best way to fix this without having to completely re-write our tests - if anyone has any insight it would be much appreciated.

Thanks

Answer 1 · 2017-03-06T11:07:12.000Z

Hi Ed,

Thanks for raising this.

Answer 2 · 2017-03-06T11:14:38.000Z

When I upgraded Verify I had to add allow_label_click to get it to pass. That’s obviously a Capybara thing, but it’s possible to drive Selenium to do the same thing. Are you using a runner for Selenium?

Answer 3 · 2017-03-06T14:05:37.000Z

There are definitely ways to overcome the issue, but they all mostly involve re-writing the tests, for example to click the label instead of the input, which was something we were hoping to avoid, as we have a lot of radios and checkboxes.

Answer 4 · 2017-03-06T16:36:59.000Z

Something else worth noting is that if the label contains a link and we tell Selenium to click the label, this will trigger a click of the link, which may not be what we want, as in this case where we want to check its corresponding input, which is why we were originally clicking the inputs and not the labels in the first place.

Answer 5 · 2017-03-07T12:53:44.000Z

The creative way we came up with to quickly solve this problem in the short term was to inject a script when Selenium runs which finds all radios/checkboxes and sets their opacity to 1.

Closing the issue as it's not really a problem with the toolkit itself.

Answer 6 · 2017-03-14T16:05:05.000Z

That’s what Digital Marketplace settled on in the end, and I believe DWP (via @adamsilver) have done the same.

I guess it might be worth experimenting in the future in setting the checkboxes / radios to opacity: 0.01 or something – low enough to not be visible in any situation but potentially enough for Selenium? Or document that as users are actually clicking on the labels that Selenium clicks should trigger a click event against the label too.

Answer 7 · 2017-03-14T16:31:48.000Z

@robinwhittleton that's not a bad idea, worth a try!

Answer 8 · 2017-03-15T08:27:03.000Z

@robinwhittleton we are waiting for the no-javascript version before attempting to run that solution.

For me, a Selenium test should test how users actually use the UI. In this case they will be interacting with the label and so tests in fact should change to accommodate this behaviour.

Interestingly, clicking the label (even if the radio button or checkbox was a native one, and not hidden), should be tested anyway, and by not testing this (for any form control for that matter) is a gap in coverage. A small gap, but a gap nonetheless.