Don't marry the mock

When you first start out writing your automation tests, you may lean towards picking a mainstay of your application to be the bedrock of your testing.

You choose this mainstay on the assumption it will always exist.

Let's say for example, the Nike Air Force 1.

A timeless classic.

Imagine you are writing automation tests for the Nike website.

Your task is to test the End to End purchasing flow of selecting an item, adding it to your basket and completing the checkout.

Your automation test might look a little something like this.

And as time goes on, your codebase grows and many of your core tests revolve around this item being available to purchase in perpetuity.

It's a bold assumption and one that can lead to a real gotcha.

Say you are faced with supplier issues, the Air Force 1 is now out of stock and isn't an item you can purchase at this fictional point in time.

What now?

Do you pick another item, refactoring your existing tests and pose the risk of your newly picked item encountering a similar fate?

I've called this "Marrying the mock" on the basis that it's common for us as engineers to predetermine what we want our tests to use.

There is another option.

Enabling your tests to pick the path of least resistance based on selectors.

In this example, we ask Playwright to find all the product cards available and pick the first one.

Playwright now has no concern for predefined product identifiers or the availability of a specific product within the test.

In a more detailed real world scenario, I would recommend exploring additional checks and assertions to validate that the item you picked is available to purchase before deciding to fail your test.

In summary, writing end to end tests to be generic without expectations can help you to avoid complex refactors and flake in your CI pipelines.