Name Validation Test Cases: Unicode, Spaces & Punctuation

Somewhere right now, a person named O'Brien is being told their own name is invalid. A signup form rejects the apostrophe. A ticketing system stores O'Brien, and a hotel confirmation prints OBRIEN. Names are the rare input that is completely legitimate and structurally hostile at once: full of quote characters, odd lengths and non-ASCII letters. That makes them some of the most valuable strings in a test suite. Download the fixed cases above for repeatable coverage. A random name generator adds variety, but it does not guarantee every edge case.

Why names are the most underrated test data

Patrick McKenzie's classic essay lists forty falsehoods programmers believe about names ^[kalzumeus]. Among them: everyone has exactly one full name, names fit in one character set, names have one correct spelling, and people have a first and a last name in that order. The W3C's internationalization group reaches the same conclusion from many cultures. Almost every structural assumption a form makes about a name is wrong for some large group ^[w3c-names].

For QA, that is good news. Each falsehood is a ready-made test case. And unlike most edge cases, these arrive on the first day you launch in a new market. A test plan built on realistic, deliberately awkward names catches the failures before your users do. Our guide to generating realistic test data applies the same idea to other fields.

The edge cases that actually break systems

These eight categories account for most name-related production incidents. The examples illustrate input patterns rather than identify customers. Names can coincide with real people; use each string to test the stated behavior.

Apostrophes and quotes

O'Brien, D'Angelo, N'Diaye. The apostrophe ends a string in SQL, quotes an attribute in HTML, and marks a character in many programming languages. Paste a name into any of them and you get a syntax error on a good day and an injection hole on a bad one. The other failure is over-correction. A rule that rejects apostrophes tells many Irish, Italian and West African surnames that they do not exist.

Hyphens, spaces, and multi-word surnames

Smith-Jones, Van Der Berg, De la Cruz, García Márquez. Code that splits a full name on spaces and calls the last word the surname mangles all of these. It files Van Der Berg under Berg and García Márquez under Márquez. Sorting, deduplication and letter greetings all inherit the error. A surname is one unit that may contain spaces and hyphens. Any code that assumes otherwise needs a test case to prove it.

Very short and very long names

Both ends of the length range are real. The Korean surname romanized as O is a single letter, and 李 is a single character. A rule of "at least 2 characters" rejects both. At the other end, real multi-part surnames pass 35 characters, and full names pass 70. That is long enough to overflow an old VARCHAR(30), cut a character in half at a UTF-8 byte limit, or break a fixed-width layout. Test one character and test forty. What happens should be deliberate in both cases.

Unicode, diacritics, and non-Latin scripts

José, Zoë, Nguyễn, 田中, محمد. Modern databases store all of them. The pipeline around storage is where they break. A connection still set to an old encoding turns accents into garbage characters. Unicode also has two ways to write an accented letter: as one character (NFC) or as a letter plus a combining accent (NFD). Two names that look identical can then fail an equality check.

Unicode's normalization report defines these forms, and the practical rule is simple. Normalize to NFC at every system boundary, then test search and deduplication with both forms ^{[unicode-nfc]}. Our German identity generator is a handy source of umlauts and ß in otherwise ordinary data. In a sample of 1,000 German profiles, 83 names had one.

Mononyms and missing name parts

Millions of people, most famously in Indonesia, have exactly one name. There is no family name to put in your required last-name field. So these users type a dot, a dash or the same name twice, and your data fills with junk. The W3C guidance and the GOV.UK name pattern both recommend one full-name field where possible, and an optional family-name field where not ^{[w3c-names] [govuk-names]}. Your test suite should include at least one profile with no last name at all.

Family-name-first order

In Chinese, Korean, Japanese and Hungarian convention, the family name comes first: in 李小明, the surname is 李. A form that maps the first word to "first name" swaps given name and surname for well over a billion people. The bug only shows up later, in a greeting that uses a customer's family name, or a legal document with the fields reversed. Test with profiles from our Chinese, Korean and Japanese generators, which write the family name first.

We have to admit something here. When we checked that sentence on 1 October 2026, it was false. Our own generators wrote 李小明 as 小明 李, given name first with a Western space, which is the exact bug this section describes. We fixed the generator the same day, for Hungarian and Vietnamese names too, and a test now holds every family-first locale to its order.

Case sensitivity and internal capitals

McDonald, MacIntyre, van der Berg, DiCaprio. Naive title-casing capitalizes the first letter and lowercases the rest. It turns McDonald into Mcdonald in every CRM export. The internal capital is part of the spelling, and the lowercase "van der" is just as deliberate. The safe behavior is to keep exactly what the user typed. Then prove it survives a round trip through normalization, storage and display.

Whitespace and invisible characters

A trailing space pasted along with a name. A non-breaking space copied from a web page. A zero-width joiner hidden in text from a messaging app. Two records that look identical but differ by an invisible byte defeat deduplication and make login by name fail for no visible reason. The usual recipe is to trim the ends, collapse inner runs of spaces, strip zero-width characters, then compare. It only earns trust when a test feeds it deliberately dirty input.

Little Bobby Tables: injection is a name problem

Did you really name your son Robert'); DROP TABLE Students;--?

The most famous name in software testing belongs to a fictional schoolboy whose mother named him after a SQL injection attack ^[xkcd-327]. The joke works because a name is untrusted input that looks trustworthy. The lesson is not to scrub names harder. It is that parameterized queries and context-aware output encoding make the string's contents irrelevant. A Bobby Tables string belongs in your fixtures not because users are attackers. It proves in one assertion that no code builds queries by pasting strings together.

How to generate edge-case names for your test suite

A fixed list like the table above is a start. Real coverage needs volume and variety: hundreds of profiles in which the awkward names arrive inside otherwise consistent identities, as they would in production. That is what a locale-aware generator is for. Our country generators produce names with each locale's apostrophes, diacritics and name order, attached to matching addresses and phone numbers. For fixture files, the bulk generator exports up to 100,000 US records as CSV, JSON or SQL inserts. It is US-only, so build other locales from the country pages.

• Mix locales deliberately. Combine Irish names, German umlauts and Chinese name order in one dataset, so every part of the system meets every category. Generate a few hundred Irish profiles: only about 1 in 100 carries an O' surname.
• Export, don't retype. Save the cases you need to a file and commit it with your fixtures, so the same awkward names run on every CI build. The bulk exporter does this for US records, and the downloads above cover the hand-picked cases.
• Cover nearby fields too. A username generator shows what the same person's handle looks like after the awkward characters are stripped. That is a separate normalization worth testing.
• Make it reproducible. Seed your generation so a failing test can rerun on identical data. See why seeding beats random test data.

Validation rules that respect real names

Testing with awkward names usually shows that validation, not storage, is the real offender. The goal is to check structure without policing vocabulary. That is the approach the GOV.UK pattern settled on after user research ^{[govuk-names]}:

• Do accept letters from any script, apostrophes, hyphens, spaces, and periods in every name field.
• Do trim surrounding spaces and normalize Unicode before comparing or deduplicating, but store what the user typed.
• Do budget generous lengths (100 characters per field) and define truncation behavior explicitly.
• Don't require a minimum of two characters, a family name, or a Latin-script spelling.
• Don't title-case, uppercase, or otherwise "fix" capitalization the user chose.
• Don't try to scrub names for safety. Parameterize queries and encode output, so the name's contents never matter.

Names as free chaos engineering

Names are free chaos engineering: a handful of fictional strings that together audit your escaping, validation, encoding, length handling and cultural assumptions. Put the starter suite above into your fixtures. Use bulk US test records for volume and the country tools for other locales. When a fixture needs one sex, use the fake female name generator or its male counterpart. Then treat every name bug you find as a falsehood you can delete from your code for good.