Names That Break Software: The Edge Cases Every Test Suite Needs

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, a hotel confirmation prints OBRIEN. Names are the rare input that is simultaneously completely legitimate and structurally hostile — full of quoting characters, unusual lengths, and non-ASCII letters. That makes them the highest-value strings you can put in a test suite, and the easiest to get from a name generator without touching anyone's real identity.

Why names are the most underrated test data

Patrick McKenzie's classic essay lists forty falsehoods programmers believe about names — that everyone has exactly one full name, that names fit in one character set, that names have a canonical spelling, that people have first and last names in that order ^[kalzumeus]. The W3C's internationalization group reaches the same conclusion from field data across cultures: almost every structural assumption a form can make about a name is wrong for some large population ^[w3c-names]. For QA, that is good news. Each falsehood is a ready-made test case, and unlike most edge cases, name edge cases arrive on day one of launching in a new market. A test plan built on realistic, deliberately awkward names catches these failures before your users do — the same philosophy behind our broader guide to generating realistic test data.

The edge cases that actually break systems

These eight categories account for most name-related production incidents. Every example below is fictional, but each pattern has a well-documented history of breaking real software.

Apostrophes and quotes

O'Brien, D'Angelo, N'Diaye. The apostrophe is a string delimiter in SQL, an attribute quote in HTML, and a character literal in half the languages your stack is written in. Concatenate a name into any of them and you get a syntax error on a good day and an injection vector on a bad one. The other failure mode is over-correction: validation rules that reject apostrophes outright, telling a sizable fraction of 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 whitespace and calls the last token the surname silently mangles all of these — filing Van Der Berg under Berg and García Márquez under Márquez. Sorting, deduplication, and letter salutations all inherit the error. A surname is one opaque token that may itself contain spaces and hyphens; any logic that assumes otherwise needs a test case that proves it.

Very short and very long names

Both ends of the length distribution are real. The Korean surname romanized as O is a single letter; 李 is a single character. Minimum-length rules of "at least 2 characters" reject them. At the other end, real multi-part and hyphenated surnames pass 35 characters, and concatenated full names pass 70 — long enough to overflow a legacy VARCHAR(30), truncate mid-character in a UTF-8 byte limit, or wrap catastrophically in a fixed-width UI. 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, but the pipeline around storage is where they break: a connection still set to a legacy encoding turns diacritics into mojibake, and Unicode's two ways of writing an accented letter — precomposed (NFC) or as a base letter plus combining accent (NFD) — mean two byte-identical-looking names can fail an equality check. The Unicode standard's normalization report defines the canonical forms, and the practical rule is simple: normalize to NFC at every system boundary, then test search and dedupe with both forms ^{[unicode-nfc]}. German profiles from our German identity generator are a convenient source of umlauts and ß in otherwise ordinary-looking data.

Mononyms and missing name parts

Millions of people — most famously in Indonesia — have exactly one name. No family name exists to put in your required last-name field, and real mononymous users resort to entering a dot, a dash, or the same name twice, polluting your data. Both the W3C guidance and the GOV.UK design system pattern for name fields recommend a single full-name field where the system allows, and an optional family-name field where it does 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 token to "first name" quietly swaps given name and surname for well over a billion people — the bug only surfaces later, in a greeting that addresses a customer by their family name or a legal document with the fields reversed. Test with profiles from our Chinese, Korean, and Japanese generators, which produce locale-correct names precisely so this mapping gets exercised.

Case sensitivity and internal capitals

McDonald, MacIntyre, van der Berg, DiCaprio. Naive title-casing — capitalize the first letter, lowercase the rest — produces Mcdonald and Vandenberg's cousins in every CRM export. The internal capital is part of the name's spelling, and the lowercase particle in van der Berg is equally deliberate. The safe behavior is to preserve exactly what the user typed and prove it survives a round trip through your normalization, storage, and display layers.

Whitespace and invisible characters

A trailing space pasted along with a name, a non-breaking space arriving from a copy-paste out of a web page, a zero-width joiner embedded in text copied from a messaging app. Two records that render identically but differ by an invisible byte defeat deduplication and make login-by-name mysteriously fail. The standard recipe — trim leading and trailing whitespace, collapse internal runs, strip zero-width characters, then compare — 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 payload ^[xkcd-327]. The joke lands because names are the canonical untrusted input that looks trustworthy. The lesson is not to sanitize names harder — it is that parameterized queries and context-aware output encoding make the contents of the string irrelevant. A Bobby-Tables-style string belongs in your fixture set not because users are attackers, but because it proves in one assertion that no code path is building queries by concatenation.

How to generate edge-case names for your test suite

A static list like the table above is a start, but real coverage means volume and variety — hundreds of profiles where the awkward names arrive embedded in otherwise consistent identities, the way they would in production. That is exactly what a locale-aware generator is for: our country generators produce names with the apostrophes, particles, diacritics, and name orders native to each locale, attached to matching addresses and phone numbers. For fixture files, the bulk generator exports up to thousands of rows as CSV, JSON, or SQL inserts you can load straight into a staging database.

• Mix locales deliberately — pull profiles from Ireland-style apostrophe-rich names, German umlauts, and CJK name order into one dataset, so every subsystem meets every category.
• Export, don't retype — generate a bulk CSV/JSON/SQL file and check it into your fixtures, so the same awkward names run on every CI build.
• Cover adjacent fields too — a username generator shows what the same person's handle looks like when the awkward characters get stripped, a separate normalization worth testing.
• Make it reproducible — seed your generation so a failing test can be re-run on identical data; see why seeding beats random test data.

Validation rules that respect real names

Testing with hostile names usually reveals that the validation layer, not the storage layer, is the real offender. The goal is to validate structure without legislating vocabulary — the approach the GOV.UK pattern codifies after user research across millions of citizens ^{[govuk-names]}:

• Do accept letters from any script, apostrophes, hyphens, spaces, and periods in every name field.
• Do trim surrounding whitespace and normalize Unicode before comparing or deduplicating — never before storing 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 sanitize names for safety — parameterize queries and encode output instead, so the name's contents never matter.

The bottom line

Names are free chaos engineering: a handful of fictional strings that jointly audit your escaping, validation, encoding, length handling, and cultural assumptions. Put the starter suite above into your fixtures, generate locale-diverse profiles in bulk so the coverage scales, and treat every name-related bug as a falsehood you can now delete from your codebase — permanently.