You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For a test case I'm currently working on [1], the only way I found to check for an element's enabled/disabled status is to query the private _element attribute directly:
find_by_id_result.first._element.is_enabled
Would it be reasonable to add an API equivalent to the existing one for visible that instead checked the enabled status of the underlying component? (I have a partially prepared patch for this, but I'm having trouble running the test suite locally on Fedora, so it isn't complete yet, and I figured it made sense to ask if the idea was acceptable in principle before continuing to work on it)
@andrewsmedina I'll file a separate issue with the test failures I'm getting running the test suite on Fedora 25. My assumption is that I'm missing some things from my environment, but I'm not familiar enough with splinter's internals yet to understand what they might be.
#545 covers that test failures I'm seeing. Some of them are clearly related to web drivers that I don't have configured, but some of the others are significantly less clear as to what is going wrong.
For a test case I'm currently working on [1], the only way I found to check for an element's enabled/disabled status is to query the private
_element
attribute directly:Would it be reasonable to add an API equivalent to the existing one for
visible
that instead checked theenabled
status of the underlying component? (I have a partially prepared patch for this, but I'm having trouble running the test suite locally on Fedora, so it isn't complete yet, and I figured it made sense to ask if the idea was acceptable in principle before continuing to work on it)[1] https://github.com/leapp-to/prototype/pull/139/files
The text was updated successfully, but these errors were encountered: