Choose the export for the test
Plain text works for quick copy and paste. JSON preserves a predictable array for fixtures and API mocks. CSV is convenient for QA matrices and spreadsheet imports; review the header and encoding in the receiving tool.
Test fixture generator
Bulk phone test-data generator
Create disposable, format-accurate fixtures for demos, seed files and automated tests. Generation happens locally in your browser.
Generate fixtures
Do not call or text generated values. Some countries do not publish general-purpose fictional ranges, so a structurally valid fixture may coincide with an assigned number.
Keep fixtures outside production
Use generated values in local development, isolated staging environments and automated tests with outbound delivery disabled. Do not merge them into customer lists, lead systems or messaging campaigns.
Document the country rule
Store the selected country and intended test condition beside the value. A fixture is more useful when a future maintainer knows whether it tests display formatting, accepted structure or a deliberate invalid length.
Build a balanced test matrix
Include at least one normal national input, one E.164 input, punctuation variants, an empty value, an unsupported calling code and boundary lengths. For delivery integrations, use provider sandbox credentials or a strict internal allowlist so a formatting bug cannot send traffic to a real subscriber.
How to use bulk fixtures safely
Bulk generation is useful when a form, import process or automated test needs many values with the same structural shape. It is not a way to build contact lists. Some countries publish reserved or drama ranges, but many do not publish broad fictional pools for general software testing. When no official fictional range exists, treat generated output as structurally plausible and keep it away from any system that can place calls, send SMS or enrich real contacts.
A good fixture file includes more than the phone string. Add the country, the expected format, the scenario name and the generation date. That makes failures easier to reproduce and prevents a future maintainer from assuming the data came from real customers. If a test only cares about formatting, there is no reason to store names, emails, addresses or any other personal data beside the phone examples.
Export format guidance
| Format | Best for | Review before use |
|---|---|---|
| Plain text | Manual QA, screenshots and quick paste tests. | Make sure the receiving tool does not auto-call or auto-message values. |
| JSON | Unit tests, API mocks and deterministic seed data. | Keep field names stable and version fixture files in source control. |
| CSV | Spreadsheet QA matrices and low-code import tests. | Check encoding, delimiters and whether leading plus signs survive import. |
For long-lived projects, combine generated positive cases with hand-authored negative cases. Random invalid data often fails for several reasons at once, which makes regressions harder to diagnose.
Release hygiene for fixture files
Before a fixture export is committed to a repository, remove any accidental real customer rows, add a short README note explaining that the values are test data, and confirm that CI cannot send outbound delivery to those values. If your team stores fixtures in spreadsheets, lock the columns that define country and expected result so later manual edits do not turn a reproducible test file into a mixed contact list.
Review exported files during code review the same way you review API fixtures. The useful parts are the scenario labels, expected formats and stable country context. The risky parts are accidental production data, values copied from real tickets and hidden spreadsheet transformations that strip leading plus signs or convert long strings into scientific notation.
Keep the generated file small enough that reviewers can actually read it, and regenerate it when the country dataset changes.
If a fixture file becomes part of public documentation, prefer documented fictional ranges and include the safety note beside the example. A bare list of plausible phone strings is less useful and easier to misuse than a small annotated fixture table.