Surname random generator

How it works

You open the generator, set a count, and receive surnames from its pool. The word surname is the column header many schemas already use. The draw is the same mechanic as any list sampler: pick an index, emit the string, optionally remove it from the next draw. Filters, if any, limit the pool before the pick, not after.

Output is a string. It may include spaces, hyphens, or particles. Your importer must accept those characters or you will spend the afternoon watching CSV tools split “De Luca” into two columns. Preview one row in the real form before you mint a thousand.

A surname random generator does not know which surname is already in your table. If you need new rows to miss existing keys, compare against the table. The tool cannot see it. Export in the encoding your app actually stores, not the one your editor guesses.

Keep a header row that says surname, not name, if those fields are split. Quote fields so commas inside surnames do not become new columns. Store the generator version next to the fixture if you will regenerate later.

Why the column is called surname

Forms disagree. One locale prints Family name. Another prints Last name. Another prints Surname. The generator’s job is the family-name string, whatever the label. If you mix generators—one for given names, one for surnames—keep the pair aligned to the same locale so a record does not combine a given name from one tradition with a surname pattern from another unless you are testing that mix on purpose.

Sorting is a separate problem. Some surnames begin with a particle that people ignore when filing. A raw Unicode sort will not match a phone book. If your UI claims “alphabetical by surname,” decide whether particles count, then test with names the generator emits that include them. Homegrown ASCII-only fixtures will never fail that code.

If your test data all share the same surname, your bugs will hide in the ones that do not.

Realism versus uniqueness

Real populations repeat surnames. Unique test users often should not, because a developer will search by last name and get one row. Decide which world you are in. For load tests that mimic a city, repeats are correct. For a demo to a client, unique surnames reduce confusion. The generator will do either if you choose replacement or not.

Do not attach extra meaning to a generated surname. It is not ethnicity proof, not gender, not a password. It is a field. If a downstream system hashes it, lowercasing rules matter: a capital letter in a particle is data. Keep the string as emitted unless your product documents a fold.

Particles and prefixes are part of the surname unless you have a dedicated field. All-caps dumps are a display choice; do not store them that way unless the product does. Empty surname is a test case your generator may never give you—add it by hand.