Unit Testing a Regex Pattern

Unit Testing a Regex Pattern

A pattern that passes on the one string you tried it against is not tested; it is only unrefuted. The gap between those two states closes the moment you write down a handful of cases the pattern must handle correctly, positive and negative alike, and check them as a group instead of trusting a single example to represent every input your code will ever see.

Why one passing example is not the same as a tested pattern

Regular expressions fail in a specific, predictable way: they usually match more than the author intended, not less. A pattern like <[A-Za-z0-9]+> written to match HTML tags also matches something like <1>, which is not a valid tag at all, because a plus quantifier happily repeats past the point the author actually meant to stop.¹ A pattern written and tested against exactly one happy-path string almost never gets caught matching too broadly, because the one string you tried never exercised the ambiguous edge the pattern actually leaves open.

Unit Tests mode exists to close that gap by treating a pattern the way you would treat a function: define a small set of inputs, decide what the correct output should be for each one, and run all of them together every time the implementation changes.² A product SKU pattern like ^[A-Z]{2}\d{4}$ looks obviously correct at a glance, yet a test batch immediately reveals whether it correctly rejects a lowercase variant or an extra trailing digit, the exact kinds of malformed input real user entry actually produces. Anchoring is what makes that verdict trustworthy: ^ matches the position before the first character and $ matches right after the last, so ^ and $ together force the entire string to satisfy the pattern rather than just some substring of it³.

Writing negative cases that earn their place in the suite

A negative test case, one explicitly marked should-not-match, is doing real work only when it targets something the pattern plausibly could get wrong, not an input so obviously invalid it was never in question. For the SKU pattern, ab1234 tests the case-sensitivity assumption directly, and AB12345 tests whether the digit count is actually being enforced rather than merely suggested by the pattern's shape.

Reading the pass count as you refine the pattern

Every edit to the pattern field re-runs the entire test batch in one pass, and the summary line above the rows reports a simple fraction: how many of your defined cases currently pass. That single number turns "I think I fixed it" into a checkable claim the moment you finish typing, rather than something you have to verify by re-reading each row individually. Each row's verdict is the boolean returned by a match test, true or false, and that boolean is the same signal a real application gets when it asks a pattern whether the input is acceptable⁴.

Iterating without losing track of which case is failing

Each row keeps its own PASS or FAIL badge visible at all times, so tightening the pattern to fix one failing case while accidentally breaking a previously-passing one shows up immediately as a badge flipping color, not as a silent regression you discover later. That immediate feedback loop is what makes iterating on a tricky pattern here faster than iterating inside application code, where you would otherwise need to re-run a whole test file just to see the effect of one small change.

Once every row shows PASS, you have something stronger than a pattern that "seems to work": you have a pattern with a specific, written-down definition of correct behavior that it currently satisfies, case by case. That written definition is what makes the pattern maintainable months later, when whoever edits it next has a concrete list of behavior to preserve instead of a single vague memory of what it was originally supposed to do.

Sharing the whole suite instead of just the pattern

A pattern shared on its own loses the context that makes it trustworthy: what it was actually tested against, and what a correct result was supposed to look like for each case. Clicking Share encodes the pattern, its flags, the test text, and every row in your Unit Tests suite, expectation included, into a single link and copies that link to your clipboard. Writing the encoded state into the address bar this way updates only what the browser displays; it never triggers a page load or a check that anything at that address actually exists.⁵

What a teammate sees the moment they open the link

Sending that link to a teammate hands them not just your pattern but the evidence it works, already loaded and ready to inspect the moment they open it. They see the same pass count you saw, can add a case you missed, and can confirm your fix actually addressed the specific input that was failing before, all without re-typing a single test string from a description in a chat message.

Because the entire suite lives inside the link itself rather than on a server, opening it later still reproduces the exact same state, pattern, flags, test text, and every row's expectation, even if the pattern in your actual codebase has since moved on. That makes a shared link a durable snapshot of "here is what I verified," worth attaching directly to a pull request or a code review comment instead of describing the test cases in prose.

When to use this

Use this guide whenever you want to pin a pattern down with a small regression suite of should-match and should-not-match cases before relying on it in code.

Examples

Pattern: ^[A-Z]{2}\d{4}$
Test strings: AB1234, ab1234, AB12345

AB1234 is marked should match and passes. ab1234 and AB12345 are marked should not match and both correctly fail, so the summary line reads 3 of 3 passing.

Testing a URL-Slug Pattern

A slug generator that mostly works is worse than one that obviously does not, because the failures only show up once a stray capital letter or double hyphen ships into a live URL. Pinning down exactly what counts as a valid slug, lowercase letters and digits, single hyphens as separators, nothing else, before that pattern reaches a routing layer or a database constraint, catches the failure while it still costs nothing to fix.

What a strict slug pattern actually needs to enforce

A URL slug has a narrower job than most strings a validator checks: lowercase letters, digits, and single hyphens used only as separators between words, with no leading, trailing, or doubled hyphen anywhere in the string. Letters, digits, hyphens, and a small handful of other characters are the "unreserved" set the URI specification exempts from percent-encoding, which is exactly why a slug built only from that set survives every URL context untouched.¹ That narrowness is exactly what makes it worth testing carefully, since a pattern that is slightly too permissive can let a genuinely broken slug slip straight through into a URL.

The tester's built-in URL slug snippet, available from the Snippets menu, encodes that rule as ^[a-z0-9]+(?:-[a-z0-9]+)*$. Anchored at both ends so a partial match at the start or end of a string cannot pass, the pattern reads as one or more lowercase alphanumeric characters, optionally followed by any number of hyphen-plus-alphanumeric groups. A capital letter, a leading hyphen, or two hyphens in a row all break that structure and correctly fail the match. The same lowercase-letters-digits-hyphens shape shows up well beyond URL slugs; Google Cloud's own resource-naming rules for Compute Engine require names to match a near-identical pattern, since infrastructure identifiers and SEO-friendly slugs both converge on the same practical, encoding-safe character set.²

Checking one candidate at a time in Match mode

Before committing to a batch of test cases, pasting a single candidate slug into the test text field and watching whether it highlights confirms the pattern behaves the way you expect on an obvious case. my-product-name should highlight as a full match; My-Product-Name should not, since the pattern has no case-insensitive flag active by default, and the engine only folds letter case when that flag is explicitly turned on.³ That quick check takes seconds and catches an obviously wrong pattern before you invest time building out a larger batch of edge cases around it.

Moving from one check to a whole batch with Unit Tests mode

Checking slugs one at a time in Match mode works for a quick sanity check, but a slug generator needs to handle dozens of edge cases correctly, not just the one you happened to think of first. Unit Tests mode is built exactly for that shift: each row holds one candidate string and an explicit should-match or should-not-match expectation, and every edit to the pattern re-runs the entire batch at once.

Building a batch that actually exercises the edge cases

A useful test batch for a slug pattern includes the obvious positive case, my-product-name, alongside the specific failures that matter most: a version with a capital letter, a version with a leading hyphen, a version with a trailing hyphen, and a version with a doubled hyphen from a bad string-replace somewhere upstream. Marking each row's expectation correctly and watching the pass count update live turns "the pattern looks right" into a verified claim backed by five or six concrete assertions.

Every PASS or FAIL badge sits directly next to its row, so a single failing case among a dozen passing ones is immediately visible rather than buried in a wall of text output. That visibility is what makes Unit Tests mode faster than re-reading the pattern by eye once your test batch grows past two or three candidates.

Deciding what happens to a slug that fails validation

A validation pattern only tells you a candidate string is invalid; it does not fix it. Most slug pipelines pair this kind of check with a normalization step upstream, lowercasing the input, replacing spaces and punctuation with single hyphens rather than underscores, since search engine crawling guidance specifically recommends hyphens as word separators over underscores, and trimming any leading or trailing hyphen the replacement step introduced, so that a failure here is rare in production rather than routine.⁴

Treating a validator failure as a signal about the pipeline

If your validator is failing regularly on real user-submitted titles, that is usually a sign the normalization step upstream needs work, not that the validation pattern itself is too strict. Re-checking a single candidate by hand means anchoring the pattern again: ^ asserts the beginning of input and $ asserts the end of input, so the same string returns a different verdict the moment either anchor is dropped⁵. Test the normalized output against this pattern, not the raw title text a user actually typed, since the two are supposed to represent different stages of the same pipeline and testing the wrong one gives you a misleading picture of where the real problem sits.

When to use this

Use this guide when you need to validate a lowercase, hyphen-separated slug pattern against a batch of candidate strings before wiring it into a routing layer or database constraint.

Examples

Pattern: ^[a-z0-9]+(?:-[a-z0-9]+)*$
Test strings: my-product-name, My-Product-Name, -leading-hyphen, double--hyphen

my-product-name is marked should match and passes. The other three are marked should not match and all correctly fail, for a pass count of 4 of 4.