I'm currently writing synthetic browser monitor scripts and am seeing a lot of failures due to timeouts -- specifically when looking for an html ID.
assert.ok($browser.waitForAndFindElement($driver.By.id("framedContent"), 5000))
$browser.waitForAndFindElement($driver.By.id("framedContent"), 5000)
is a promise that waits before looking for the ID "framedContent". I'm wondering if it's plausible that the assert.ok isn't "smart" enough to wait for the promise to fulfill, even though it technically can take a promise as input?
The assert.ok
docs declare that assert.ok
just tests for truthiness. All Promise objects are truthy, resolved or not, because all Javascript objects are truthy. Aside from that, assert.ok
is synchronous and couldn't react to an asynchronous Promise's result anyway.
You might reach for assert.doesNotReject
, which does accept a Promise and does wait for the result, but it also behaves asynchronously and returns a Promise. This won't be better than your bare call to waitForAndFindElement
, as described in the docs:
Using
assert.doesNotReject()
is actually not useful because there is little benefit in catching a rejection and then rejecting it again. Instead, consider adding a comment next to the specific code path that should not reject and keep error messages as expressive as possible.
For that reason, you may need to await
your waitForAndFindElement
in order to turn it into the kind of error that will actually (appropriately) wait for your element to appear or make your test fail otherwise.