Question 1

What is the difference between test() and match(), and when do you pick each?

Accepted Answer

regex.test(text) just returns true/false — for the "does it match?" question. text.match(regex) gives you the match itself: without the g flag, [0] is the whole match, [1], [2] are capture groups and .groups holds named ones; with no match it returns null. My rule: test() when I need no data, match() when I need to extract a value. Whenever I use match() I guard it with ?., because indexing into null is the most common regex mistake in test code.

Question 2

Where do you use regex in Playwright?

Accepted Answer

Mainly in four places: (1) toHaveURL(/\/orders\/\d+$/) — when the URL carries a changing id or query string; (2) toHaveText(/^\d+ items?$/) — checking the SHAPE of text when a count or date varies; (3) getByRole('button', { name: /sign in/i }) — a locator tolerant of case and minor wording differences; (4) filter({ hasText: /paid/i }) — selecting table rows by content. The point to stress: regex here exists to make the test less brittle — when the exact value is not stable, binding to the shape is the right call.

Question 3

What are the risks of using regex?

Accepted Answer

Three main risks: (1) an over-permissive pattern — a /dashboard/ check also passes on /old-dashboard-archive; the fix is anchoring with ^/$ and \b; (2) unreadability — nobody understands a 60-character pattern a month later, so I extract complex patterns into a named constant with a short comment; (3) catastrophic backtracking (ReDoS) — nested repetition ((a+)+) can effectively hang execution on long input; rare in test code but a real problem when parsing large log files. On top of that, chasing a "perfect" email regex is pointless — a simple shape check is enough, real validation is the backend's job.

Question 4

How do you decide how strict an assertion should be?

Accepted Answer

I frame it as: if this value changes, is failing the right behaviour? If yes — an exact comparison (toHaveURL('...'), toBe(...)). If the value changes for reasons outside the test (a count, a date, a generated id) — I bind to the shape (regex, type check, enum set). An over-strict assertion creates noise: the team patches the test every week and eventually stops trusting failures. An over-loose one lets real regressions through — a /\d+/ check happily accepts the wrong number. My balance: structure is always asserted strictly, values strictly only where the test itself controls them.

Pattern	What it matches	Use in tests
/^\d+$/	a whole string of digits only	validating an ID or count field
/\d+/	the first digit group INSIDE the text	pulling a number out of 'Order #1042'
/^[^\s@]+@[^\s@]+\.[a-z]{2,}$/i	a simple email shape	the format of a generated email
/^[0-9a-f]{8}-[0-9a-f]{4}/i	the beginning of a UUID	the shape of an id returned by the API
/\s+/g	runs of whitespace and line breaks	normalising UI text (with replace)
/(?<id>\d+)/	a named capture group	readable extraction via match().groups.id

Regex basics for testers

📚 Sources and documentation