Conditional Testing

Conditional testing can be described in this simple pseudo-code:

If A
    Do B
Else
    Do C

We usually need these kinds of tests when we want to:

• Test things differently based on the presence of an element.
• Cope with A/B testing in the background.
• Do dynamic testing based on the content of our app.

---

The problem with conditions in tests

There is a fundamental problem with these types of tests. While we can easily write them, they often lead to flaky tests and random failures, making tracking these failures harder.

We can only write conditions once the state of the application has settled. However, it is often impossible to know when that is, especially with highly dynamic SPAs. This instability can cause the previously mentioned random failures and flakes.

---

Possible solutions

There are possible solutions to the problem, but it’s important to mention that they will not be bulletproof. They can only reduce flakes. But if we need to have conditions in our test, it will never fully eliminate them.

Being explicit

One way we can fight flakes and random errors is by being explicit.

Imagine our site has multiple tests running that can ultimately alter the result of our E2E tests. In this case, we want to be explicit about which variation of the A/B test the user will receive, whether it be by:

• Setting query params
• Settings cookies or other local storage
• Setting headers

// You want to make sure that the test runs with the same set of conditions at all times.
cy.visit('https://webtips.dev?campaign=A');

Callbacks

If we need to, we can also conditionally query for elements using .then chains.

For example, you know for sure that one of two elements will be present on the page, but you don’t know which one. You are doing experiments between a banner and a popup.

We can use cy.get('body'), since body will always be present, and query for the necessary element to see if it is present: