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

has_some_element? doesn't check for uniqueness #47

Open
ineverov opened this issue Apr 22, 2020 · 4 comments
Open

has_some_element? doesn't check for uniqueness #47

ineverov opened this issue Apr 22, 2020 · 4 comments
Labels
Bug Fix Something isn't working documentation Improvements or additions to documentation Feature Request

Comments

@ineverov
Copy link
Contributor

ineverov commented Apr 22, 2020

Issue to raise for SitePrism framework

supposed there is an element some_element defined as

element :some_element, 'li'

and code

if some_page.has_some_element?
  some_page.some_element
end

Above example will raise an error if li element is not unique on the line
some_page.some_element :
Capybara::Ambiguous Exception: Ambiguous match, found N elements matching visible css "li"

This is happening in

def element_exists?(*find_args)
there we check for a selector, but not providing count: 1 option for element.

This issues can be seen in various places there?(:some_element), all_there? etc will also return true for above example. But will fail if you try to interact with element

Environment

  • all

Expected Behavior

has_some_element? to return false (maybe with warning "found multiple elements")

Actual Behavior

has_some_element? returns true but some_element fails with above error

Proposed workaround

 module Fix                                                                                                                  
   def element(name, *find_args)                                                                                             
     hash_args = find_args.last                                                                                              
     hash_args.merge!(count: 1) unless hash_args.has_key?(:count)                                                            
     super(name, *find_args)                                                                                                 
   end                                                                                                                       
   def section(name, *find_args)                                                                                             
     hash_args = find_args.last                                                                                              
     hash_args.merge!(count: 1) unless hash_args.has_key?(:count)                                                            
     super(name, *find_args)                                                                                                 
   end                                                                                                                       
 end                                                                                                                         
                                                                                                                             
 SitePrism::DSL::ClassMethods.prepend(Fix)
@ineverov ineverov changed the title has_element_name? doesn't check for uniqueness has_some_element? doesn't check for uniqueness Apr 22, 2020
@luke-hill
Copy link
Collaborator

SO what do we think about the following business questions.

  • If the check for an element is ambiguous, the acting on that element would be ambiguous, are we happy with this?
  • Do we think users would check if an element is present then act on it. If so, what would be the desired behaviour?
  • Can we remedy this in a backwards compatible way?

My opinions

  • I am happy with the current behaviour
  • I am happy that this might be a valid use case, I think returning true is the correct behaviour though, with some warning
  • I think we should allow the boolean check to possibly return either true or false based on a config flag, that way we cover our bases.

@luke-hill luke-hill added Awaiting Response documentation Improvements or additions to documentation Needs decision This doesn't seem right labels Apr 24, 2020
@ineverov
Copy link
Contributor Author

@luke-hill The problem I'm facing is the following:
I have a page object (SomePage) with the expected elements defined.
In the test case, I want to check if elements are all there before performing other asserts.

some_page = SomePage.new
expect(some_page).to be_all_there
# .... some steps ....

some_page.some_expected_ ambiguous_element.some_method

The first time I noticed this issue, I was like Crap I missed it in expected_elements. But then I realized all_there? returns true even though the element is ambiguous. I'd want my test to fail expect(some_page).to be_all_there check. Ideally with some verbose message (I'll raise another issue about it with a request to add RSpec matcher for all_there?).
I agree about config option like ambiguous_check = true/false

@luke-hill
Copy link
Collaborator

luke-hill commented May 3, 2020

So in solution we propose the following (For now in the 3.x branch).

  1. A new config option. Which by default is set to false. When set to true. Any call to has_xxx? for section or element which has 2+ will fail. Will need a new custom exception writing.
  2. A logging option. Which every time a call to has_xxx? is called for section or element returns a value of 2+ will log a WARN level message that the value found was not unique.

@ineverov
Copy link
Contributor Author

@luke-hill sounds like a plan. I'll try to work on it anytime soon

@luke-hill luke-hill removed the Needs decision This doesn't seem right label Jun 3, 2020
@luke-hill luke-hill added the Bug Fix Something isn't working label Jul 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Fix Something isn't working documentation Improvements or additions to documentation Feature Request
Projects
None yet
Development

No branches or pull requests

2 participants