Can't test pages using Material UI with Capybara

[CamJN]

It is literally impossible to test material ui using capybara+selenium-webdriver

• [x] This is a v1.x issue.
• [x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

This library should not use elements so wrongly that it is impossible to test projects that use it with standard automated tools.

Current Behavior

Material-ui currently abuses elements so thoroughly that there is currently no way to test pages that use material-ui using capybara/selenium-webdriver.

Steps to Reproduce

codesandbox.io can't handle ruby deps, so no point in setting anything up there. Link: I'll fill this in when i have a second

1. Create a Switch element on the page (non-native because otherwise you can't use multi-select)
2. try to select an option from it using capybara
3. you can't, it's literally impossible, you can get as far as clicking the option in the popup, but then selenium throws an unknown error because it can't understand the dom anymore

Selenium::WebDriver::Error::UnknownError: unknown error: option element is not in a select

Context

I'm trying to write tests for my project, using capybara & a headless browser driven by selenium-webdriver.

Your Environment

Tech	Version
Material-UI	v1.4.1
React	16.4.6
headless Firefox	62.0b12
headless chrome	68.0.3440.75
capybara	3.1.0
selenium-webdriver	3.12.0

[mbrookes]

I'm assuming you only came to vent, and hope it made you feel better, but there's nothing here that would encourage anyone to try to help you.

[support[bot]]

👋 Thanks for using Material-UI!

We use the issue tracker exclusively for bug reports and feature requests, however, this issue appears to be a support request or question. Please ask on StackOverflow where the community will do their best to help. There is a "material-ui" tag that you can use to tag your question.

If you would like to link from here to your question on SO, it will help others find it. If your issues is confirmed as a bug, you are welcome to reopen the issue using the issue template.

[scottschafer]

In case anyone is looking at this in 2024, this bug report may have come across as abrasive, but speaking as a developer converting frontend code to use Material-UI controls with a ton of Capybara tests, I completely understand the frustration here.

It's a horrible experience. The controls are literally on the screen, and capybara can't find them.

It took me a while to figure this out. The problem is that the opacity of input controls within Material-UI rendered controls is 0, making them invisible to Capybara.

My solution is to have a SASS file included when in the test environment containing this:

.MuiCheckbox-root, .MuiFormControlLabel-root
  input
    opacity: 0.00001 !important

I'm still refining this, but this generally seems to work. I think Material-UI could have a non-zero opacity for native controls out of the box and it would save much aggravation.

[mbrookes]

@scottschafer Thanks for some actionable insight. I can't promise that it will get fixed any time soon (five years with no upvotes! 😅) but at least it's on our radar.

[scottschafer]

You bet. What I ended up doing in addition to tweaking the CSS slightly when in test mode was to write some wrapper classes around etc so that they render a regular element when running in test mode. The

receives the id and is kept in sync with the MUI control so that its onChange triggers the onChange in the props. So then I just replace { if (!showTestableField()) { return ; } return {renderMenu(props, extractOptionsFromSelect(props))} ; }; On Wed, Jan 17, 2024 at 2:35 PM Matt ***@***.***> wrote: > @scottschafer Thanks for some > actionable insight. I can't promise that it will get fixed any time soon > (five years with no upvotes!) but at least it's on our radar. > > — > Reply to this email directly, view it on GitHub > , > or unsubscribe > > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >