What would you test in unit tests for an address normalization function?

What would you test in unit tests for an address normalization function?

• A. Diacritic removal
• B. Abbreviation mapping
• C. Casing
• D. All of the above

Answer: (D)

A key aspect of testing an address normalization function is ensuring it produces a stable, canonical form regardless of input variations. To do this well you must verify diacritic removal, abbreviation mapping, and casing because each can change how an address looks even though it refers to the same place.

Diacritic removal matters because many addresses include accented characters. The normalizer should map these to their base letters so that versions like São Paulo and Sao Paulo are treated identically, preventing mismatches in comparisons or lookups. Abbreviation mapping handles the common shorthand you’ll see in addresses, such as St, Ave, or Blvd. Testing should confirm that these abbreviations are converted to the standardized term your system uses, so “St.” or “St” ends up in the same canonical form as the full street type you expect. Casing tests ensure inputs in mixed or unexpected case forms still yield a consistently cased, canonical result, like turning “123 MAIN st.” into “123 Main Street” (or whatever your chosen convention is).

Because each of these factors can independently affect the final normalized string, covering all of them together ensures the function is deterministic across real-world inputs. In practice, you’d include test cases that mix diacritics, abbreviations, and varying casing, plus edge cases like empty or null inputs, to confirm the normalization rules hold consistently. That’s why testing all of these aspects together is the best approach.