-
Notifications
You must be signed in to change notification settings - Fork 6
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
Should browser-monkey really do all those assertions? #74
Comments
sounds like a good experimental API that could become v3 👍 |
major problem here is that browser monkey retries assertions until they pass (or until timeout) - if we can get this to work with custom assertions then i'm in favour ;) |
Yeah, good point! Maybe there's not much difference when you factor that stuff in. The way this works in capybara is that the driver answers a query, which eventually returns false, so: async browser.exists(options) // => returns false ...it's then up to the assertion framework to assert it exists or describe the failure, e.g: assert(await browser.exists(options), `Expected element to exist with ${options}`) |
FWIW I think a wise strategy when waiting for something to exist, is wait for the smallest piece of evidence that it exists. In the example above, I think you generally want to be waiting for |
Also, you know.... perhaps the retrying isn't really browser-monkey's responsibility either 😲 assert.eventuallyDeepEqual(browser.find('ul.monkey-species li').text(), [
'Olive Baboon',
'Patas Monkey']
) |
Is it? ....really?
I think it's core strength is actually finding and manipulating elements in a DOM. To back up this statement, consider the fact that the first example in the readme does no assertions!
I feel like maybe assertions should be left to the user. So perhaps I would rather express this:
...as this:
As a result:
What do you think?
The text was updated successfully, but these errors were encountered: