-
Notifications
You must be signed in to change notification settings - Fork 163
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
Testing autocompleters #188
Comments
Interesting case indeed. @stof , any ideas? |
I've run into similar problems testing an autocomplete using typeahead.js. You can use the following code to work around the issue (from a RawMinkContext-extending class)
This basically enters data, waits for the autocomplete keeping the focus and then selects the first item by simulating keyboard input. It will work for typeahead but might need some adaptation for other autocompletes. The thing is, this solution is tied to the implementation of the Selenium-driver. We are trying to find a way to input data into a textbox but without losing the focus. Looking at the implementations of the other drivers I'm not even sure that the concept of 'enter data but keep the focus' can be ported to those drivers! You might be stuck using this code and tying your tests in strongly with Selenium... |
IMO, the new behavior is the expected one for The case of testting an autocompleter is that you are testing something happening during setting the value, not after setting it. |
yeah, it is probably the way to go |
I'm testing an application with Behat, Mink and Selenium 2 that has some input fields with autocompleters. A typical autocompleter is rendered as a
<div>
below the input field that is displayed as long a the input field is focused.Before v1.2 of the driver, we could test those as described in the example in the manual. With v1.2, due to PR #146, the driver automatically sends a tab key after filling in the value into the input field, which causes a blur event on the input field which closes my autocompleter.
Sending the tab automatically probably triggers the expected behavior (= change event) in 98% of the cases people use your driver in, but in my case it breaks my test. Now, I was looking for a way to fill text into an input field without triggering a blur event, but I really have no idea how to do this, since this behavior is hard-wired to the
setValue()
method of the driver.The text was updated successfully, but these errors were encountered: