DEV Community: Zoe Clegg

Cousin locators in Playwright

Zoe Clegg — Sun, 02 Nov 2025 22:17:47 +0000

When your page renders multiple instances of the same element or component, your locator strategy needs to reliably be able to target the specific element that our test cares about.

Using indexes might not work if the order or count of the elements is not consistent. Using dynamic test IDs (such as edit-${username}-button) can sometimes be complex to create and might be brittle depending on the formatting of the dynamic part of the locator.

Using what I call ‘cousin’ locators to help fetch the element you want is a much more robust and reliable solution.

Using cousin locators

In the example below, I want to click the ‘Edit’ button for the user Dawn Summers.

If we just try clicking on the edit button like below, the test will fail as there are multiple elements that match that locator.

await page.getByTestId('edit-profile-button').click()

So we need to narrow down our search so it only looks at the button in Dawn’s profile container.

We can start by choosing a unique element inside each container. User ID is a good example in this scenario. Assuming Dawn’s user ID remains constant between test runs, we can get this element using the following:

page.getByTestId(‘user-id’).filter({hasText: ‘920437’})

From this, we can work upwards to get the user container.

getProfileContainer(userId: string) {
  const userIdElement = page.getByTestId(‘user-id’).filter({hasText: userId})
  return page.getByTestId(‘profile-container’).filter({has: userIdElement})
}

Now that we have the correct profile container, we can look within this container and click on the edit button we need.

async clickEditProfileButton(userId: string) {
  const profileContainer = getProfileContainer(userId);
  await profileContainer.getByTestId(‘edit-profile-button’).click()
}

And that’s it. We can now reliably click the corresponding button based on the user ID we’ve supplied. Here’s a full look at this code in a page object model file.

export class profileList {
  readonly page: Page;
  readonly profileContainer: Locator;
  readonly userId: Locator;
  readonly editProfileButton: Locator;

  constructor(page: Page) {
    this.page = page;
    this.profileContainer = page.getByTestId(‘profile-container’);
    this.userId = page.getByTestId(‘user-id’);
    this.editProfileButton = page.getByTestId(‘edit-profile-button’);
  }

  getProfileContainer(userId: string) {
    const userIdElement = this.userId.filter({hasText: userId})
    return this.profileContainer.filter({has: userIdElement})
  }

  async clickEditProfileButton(userId: string) {
    const profileContainer = this.getProfileContainer(userId);
    await profileContainer.locator(this.editProfileButton).click()
  }

}

Understanding the Birthday Paradox in Software Development

Zoe Clegg — Sat, 18 Oct 2025 16:06:48 +0000

If your code generates IDs or keys using some kind of random generator then it’s important that it generates unique values and not ones already in use. Universally Unique Identifier (UUID) is a widely used identifier which is usually a 36 character string, but depending on your use case you might not need something this long - particularly if the ID needs to be user-facing. But how do you know how many characters is enough? This is when the Birthday Paradox comes into play.

What is the Birthday Paradox?

In a room of just 23 people, there is a 50% chance that at least two of them share a birthday. Given that there’s 365 possible dates for each person’s birthday, it doesn’t sound right that you’d only need 23 people for that statement to be true. That’s why it’s called the Birthday Paradox.

The maths behind it

Let’s say that p(n) is the probability that in a room with n people, nobody shares a birthday. This means 1-p(n) is the probability that at least two people share a birthday.

If there’s only one person in the room, they could have a birthday on any date, since there’s no one to share it with. So they have a 365/365 chance of not sharing a birthday.

When a second person enters the room, in order for them not to share a birthday with the first person, they have a 364/365 chance. A third person would have 363/365, and so on…

To determine the probability of all of the above statements to be true, we multiply the probabilities together. So the probability that none of them share a birthday is:

p (n) = (365/365) * (364/365) * (363/365) * \dots * (365 - (n - 1) /365)

So when n = 23, this means p(23) = 0.4927

Therefore, 1 - p(23), the chance of at least two people sharing a birthday is 0.5073.

What does this mean for development?

If we replace birthdays with ID values, the chance of two randomly generated IDs being the same is higher than you might intuitively have expected. In software, a clash could lead to errors, security risks or even data being overridden. Therefore it’s important to ensure that the number of possible unique IDs is large enough that the chance of the same ID being used twice is extremely low.

The number of possible ID values you need is directly connected to the number of IDs you might expect to generate over the lifetime of your software.

Let’s say your IDs refer to users of the software. Are you likely to be dealing with hundreds, thousands, millions or even more users?

You can use this Birthday Paradox Calculator to work out how many possible ID values you should have to minimise clashes.

Ways to combat the birthday paradox

There are three common approaches to mitigating the birthday paradox:

Increase the length of the ID: more characters means more possible ID values
Allow more character types: using a combination of letters, numbers and symbols leads to more possibilities
Implement a retry: as a fallback, if a generated ID already existed, generate another ID until it is unique

Six practical tips to improve your bug reports

Zoe Clegg — Thu, 02 Oct 2025 10:06:17 +0000

A poorly written bug report wastes time if it doesn’t include the information needed to prioritise and fix it. Here are some practical tips to help you get it right the first time and avoid unneeded back-and-forth with developers and product managers.

1. Write a report everyone can understand

Bug reports aren’t just for testers and developers - other stakeholders such as product managers and designers might also read them for prioritisation or other purposes. That doesn’t mean you should exclude technical details (such as error logs or environment details), but it does mean you should include summaries and reproduction steps that everyone can follow.

2. Be clear

‘User can’t submit form’ doesn’t really convey what the problem is. Does nothing happen when the user clicks the submit button? Is the button disabled when it shouldn’t be? Is the button not visible? There are lots of ways to interpret this, so be sure to include the key details of the issue with clear reproduction steps.

3. Include full-page screenshots or videos

If the problem involves a UI, ensure you include screenshots or videos that capture the whole of the page - including the URL of the page. Screenshots that are just small snippets of a page don’t always cut it. It should be immediately clear what page the user is on and where on the page the bug is (don’t be afraid to annotate your screenshots for extra clarity). This can help others locate the issue quickly.

4. Create one report per bug

Unless you’re fairly confident that two issues are due to the same bug in the code, it’s always best to create separate bug reports for each issue. This allows each issue to be managed individually and tracked more effectively. This also prevents bugs from getting lost or forgotten.

5. Highlight the impact of the bug

Bugs that affect critical flows, cause poor user experiences or are potential security risks should be fixed quickly, so it’s important to make the bug’s impact clear in your report. This gives others the context they need to determine its priority. If the problem is only cosmetic or doesn’t affect user behaviour, mention that too.

6. Learn from the questions your reports get

Every time someone asks you a question about one of your bug reports, think about how the answer could have been incorporated into the bug report from the start. This will show you what other information you should start including. But be careful, the more bloated your bug report is, the more likely it is that others will skim read it and end up asking you questions that your bug report already answers.