Six reviewed happy-path cases

CountryInputRegionExpected E.164Rule under test
Italy312 345 6789IT+393123456789Keep all ten mobile digits; do not generalize zero removal to geographic numbers.
Russia8 900 123-45-67RU+79001234567Replace the domestic 8 with +7 and retain ten national digits.
Brazil(11) 98765-4321BR+5511987654321Preserve the two-digit area code and nine-digit mobile subscriber number.
Bangladesh01711-123456BD+8801711123456Remove the domestic zero before +880.
France06 39 98 12 34FR+33639981234Remove the domestic trunk zero before +33.
India98765 43210IN+919876543210Add +91 to the complete ten-digit national value.

A small JavaScript contract

const cases = [
  { region: "IT", input: "312 345 6789", expected: "+393123456789" },
  { region: "RU", input: "8 900 123-45-67", expected: "+79001234567" },
  { region: "BR", input: "(11) 98765-4321", expected: "+5511987654321" },
  { region: "BD", input: "01711-123456", expected: "+8801711123456" },
  { region: "FR", input: "06 39 98 12 34", expected: "+33639981234" },
  { region: "IN", input: "98765 43210", expected: "+919876543210" }
];

for (const item of cases) {
  assert.equal(normalize(item.input, item.region), item.expected);
}

The exact parser API depends on the maintained library you choose. The important part is the explicit region and expected value. A regex that only removes punctuation cannot implement trunk-prefix or shared-plan rules safely.

Negative cases belong beside positive cases

For each reviewed country page, GetPhoneNum also documents one-digit-short input, ambiguous international context and a claim the tool must not make. A production suite should add one digit too long, unsupported prefixes, extension handling, copied non-breaking spaces and a country change after the user has typed digits.

Expected failures should name one reason. “Invalid phone number” is too broad for a regression test because it cannot reveal whether the parser, numbering metadata or product rule changed.

Separate normalization from verification

Producing +393123456789 proves only that the input was transformed according to a fixture contract. It does not prove current allocation, carrier, reachability, user control or consent. Store verification state in a separate field and expire it according to the product's security requirements.

Why these six cases were selected

The matrix is intentionally small and varied. Italy demonstrates why a zero-removal shortcut is dangerous. Russia tests replacement of a domestic dialing prefix and a shared calling plan. Brazil preserves an area code and a mobile-specific extra digit. Bangladesh and France exercise domestic trunk removal with different country-code lengths. India provides a closed ten-digit mobile-shaped input without a trunk prefix in the stored fixture.

Together they expose mistakes that a punctuation-only formatter cannot catch. They are not a substitute for a complete numbering library; they are a compact regression set that makes the expected transformation visible during code review.

Reviewing a failed assertion

When a test changes after a metadata upgrade, first compare the library version, selected region and original input. Then verify the national source before updating the expected value. Do not automatically approve a new output because the dependency is newer. A changed result can reveal a legitimate numbering-plan update, an altered default region or a regression in trunk handling.

Record the decision in the fixture changelog and update the country guide, dataset and test expectation in the same release. That keeps documentation and executable behavior aligned.

How to reproduce these results

  1. Download the dataset version shown on the dataset page.
  2. Use the ISO region as explicit context for national inputs.
  3. Normalize punctuation without losing meaningful digits.
  4. Apply the country's documented trunk rule.
  5. Compare the exact output with the expected E.164 fixture.
  6. Repeat after every numbering-library or metadata upgrade.