How to Test Regular Expressions Before Using Them in Code
A regular expression either does exactly what you meant or something subtly different, and the second kind does not announce itself. It runs, it returns matches, and the matches are wrong. The Regex Tester shows every match highlighted in real text so you can see what the pattern is actually catching.
Test against the awkward cases, not the easy one
Everyone tests the example that made them write the pattern. The bugs live elsewhere: the empty string, the line with trailing whitespace, the entry with a unicode character in it, the one where the field is missing entirely, and the one where the thing you are matching appears twice on the same line.
Paste a realistic sample rather than a tidy one. If you are matching rows from a log, use twenty actual rows including the malformed ones. The pattern that handles your clean example and fails on a blank line will fail in production on exactly that blank line.
Four mistakes behind most regex bugs
Greedy matching. The quantifiers are greedy by default, so a dot followed by a star takes as much as it possibly can. Matching from the first quote to the last quote on a line with two quoted strings gives you one match spanning both. The lazy form stops at the first opportunity instead.
Unescaped dots. A dot matches any character, so a pattern for a file extension matches far more than you intended. Escape it when you mean a literal full stop.
Missing anchors. Without a start and end anchor you are asking whether the pattern appears somewhere, not whether the whole string is that pattern. A validator without anchors accepts anything containing a valid value.
Character class confusion. Inside square brackets most special characters lose their meaning, which is convenient and surprising - a dot inside a class is just a dot.
Know when to stop
Some things look regular and are not. HTML is not, email addresses are very nearly not, and nested structures genuinely cannot be matched by a regular expression at all. If your pattern is growing past a line or two, the problem probably wants a parser. A regex nobody can read is a bug waiting for whoever maintains it next, including you in six months.
Common questions
Why does my pattern work in one language and not another?
Dialects differ - lookbehind, named groups and unicode classes are not supported everywhere. Test in the flavour you will deploy in.
How do I match something case-insensitively?
With the case-insensitive flag rather than by writing both cases into the pattern, which doubles its length and its bugs.
Can I use a regex to validate an email address?
Only roughly. The full specification is far more permissive than anyone expects. Check for one at sign and a dot after it, then send a confirmation email - that is the only real validation.
Should I comment a complex pattern?
Always, in the code around it. Write what it is meant to match in plain words, because the pattern will not tell the next reader.
Got a pattern to check before it ships?