I haven't seen a way to check for the existence of an element without using a waitFor or an expect. We have an app that stores data offline and will automatically log in the user based on the cached data. What I would like to do is have the ability to check whether an element exists and based on that decide whether we need to run through the full login sequence or just return. Has anyone ran into a need for something like this or even better found a solution?
@jarredwitt So, what's wrong with expect to check an element and do something if it exists and do something else if not? Not sure understand you.
@isnifer expect throws if it can't find the element correct? Looking for something that returns true/false if that's available.
@jarredwitt expect throws - correct. For example, login via Facebook, the code under will be not for Detox, but it is great answer for your problem:
let usernameInputId
let passwordInputId
try {
// If we can't find an element with one id
await driver.waitForVisible(usernameFieldId, 30000)
usernameInputId = usernameFieldId
passwordInputId = passwordFieldId
} catch (e) {
// We will go to catch try to find another element and set correct ids for test
await driver.waitForVisible(usernameFieldIdAlternative, 30000)
usernameInputId = usernameFieldIdAlternative
passwordInputId = passwordFieldIdAlternative
}
So, just use try-catch to expect both cases
@jarredwitt why Facebook? Because sometimes they show different forms for login.
@isnifer thanks for the example. I can make something like that work. Do you know of any plans to add an exists type matcher that returns true/false? Just would like to rely on try/catch blocks for actual errors instead of just checking if an element exists to run different logic.
@jarredwitt I'm sure you should use try/catch right now, because true/false it is not how detox works or how another testing frameworks work.
What I would like to do is have the ability to check whether an element exists and based on that decide whether we need to run through the full login sequence
A test should generally start in a well known state, so that it is easily repeatable. Generally it can be considered an anti-pattern if your tests are conditional. In this particular case it seems like there should be two separate tests for your two flows. One for describing when it's a fresh app with no previous use, and another for when it has been successfully cached etc.
Hello,
We are moving support questions to Stack Overflow. Please ask a question there with the detox tag. This section is only meant for Detox issues and enhancement requests.
Thanks
Clickable links to SO:
Most helpful comment
@jarredwitt expect throws - correct. For example, login via Facebook, the code under will be not for Detox, but it is great answer for your problem:
So, just use
try-catchto expect both cases