Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Smart is_displayed #15

Open
mfalesni opened this issue Jan 26, 2017 · 2 comments
Open

Smart is_displayed #15

mfalesni opened this issue Jan 26, 2017 · 2 comments

Comments

@mfalesni
Copy link
Contributor

Currently, we have is_displayed that only returns true or false without further explanation. It would be helpful to see which exact part of the is_displayed failed. Therefore I would propose this:

  • Create a descriptor that will be set as is_displayed instead of the property and will hold a set of rules/checks for the displayed check.
  • The descriptor would implement __nonzero__ to act as a boolean value, therefore making it usable in if and such expressions.
  • On the __nonzero__ resolution it would store the result of each partial check in some sort of dictionary.
  • It would provide a method that would either directly raise an exception or just provide an information about those checks that did not pass.
if not view.is_displayed:
    raise Exception(view.is_displayed.why)

Or something like that, this is just a concept. (the sample provided would have caching problems)

The rules would be flexible - a string could represent either widget name (it would call is_displayed on that one) or if it would not be a widget then it would assume it is an attribute to be read. It could also provide some basic checkers like you could do a value comparison ... the discussion is open.

@psav
Copy link
Member

psav commented Jan 26, 2017

My main issue with is_displayed relates to the selenium implementation we have that pulls elements back all the time. We discussed doing something in JS for this instead for the situations where we have a locator.

@mfalesni
Copy link
Contributor Author

It would be interesting if we had a way to analyze and join xpath locators, that way we could just throw them together, use a long xpath for a quick check and if it is not displayed do a deeper analysis using separate locators. Remember widgets usually spit xpath. And CSS locators should be translatable to xpath as well :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants