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

Should browser-monkey really do all those assertions? #74

Open
joshski opened this issue Jun 15, 2017 · 5 comments
Open

Should browser-monkey really do all those assertions? #74

joshski opened this issue Jun 15, 2017 · 5 comments

Comments

@joshski
Copy link
Member

joshski commented Jun 15, 2017

Browser Monkey is a DOM assertion library

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:

await browser.find('ul.monkey-species li').shouldHave({ text: [
  'Olive Baboon',
  'Patas Monkey']
})

...as this:

assert.deepEqual(await browser.find('ul.monkey-species li').text(), [
  'Olive Baboon',
  'Patas Monkey']
)

As a result:

  • I can use whatever assertion library I want
  • My tests throw assertion exceptions, instead of some framework
  • The browser-monkey API has a smaller surface area, so it's easier to learn and maintain

What do you think?

@dereke
Copy link
Member

dereke commented Jun 15, 2017

sounds like a good experimental API that could become v3 👍

@refractalize
Copy link
Member

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 ;)

@joshski
Copy link
Member Author

joshski commented Jun 15, 2017

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}`)

@joshski
Copy link
Member Author

joshski commented Jun 15, 2017

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 ul.monkey-species to exist, then synchronously asserting on the li items inside it. There's a subtle difference between that and waiting for a more complex thing (such as the list with the items in it) but it's an important difference in my mind. Mixing the assertions with the finding makes it difficult to know exactly what the test is doing IMO.

@joshski
Copy link
Member Author

joshski commented Jun 15, 2017

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']
)

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

3 participants