SSN for test fixtures
This page covers moving the synthetic SSN from the generator into a test suite: which value to hardcode in a fixture, how to keep runs reproducible, and what to check when a form field applies an automatic mask.
Typing the 9 raw digits should reformat live to AAA-GG-SSSS; the 3+2+4 digit split matches the same slicing the generator uses to build area, group and serial.
A contract test confirms the API accepts a structurally valid but synthetic SSN, and rejects a clearly invalid one, such as area 666 or serial 0000, without ever querying the real SSA.
A staging environment should never call real verification; this value clears the local checks so QA can finish the flow end to end without an external dependency blocking it.
No. Common validation is based on structure and excluded ranges, not a checksum.
Yes, by default the choice is random on every call. For a reproducible fixture, copy the value once and hardcode it in the test file instead of generating it inside the run itself.
The generator automatically remaps an attempted area of 666 to 667, because 666 sits on the SSA exclusion list. Document that behavior if your test depends on a specific area value.
It depends on what the component receives: store the 9 raw digits when the test is about a typing mask, and the dashed version when the test only checks display or an already-formatted payload.
Only if the cases run in isolation. On a shared staging database with a uniqueness rule on SSN, generate a fresh value per case so it does not collide with a record left behind by an earlier test.
Generation happens locally in the browser. Analytics receives only action, status, type and format, never the generated SSN.