Putting real values in test data means that what you think is a test reaches an actual person. The classic failures are a verification email landing in a real inbox and an SMS arriving on a stranger's phone. This article covers the reserved ranges you can safely use, and how to think about names and addresses.
example.com for domains, 192.0.2.0/24 for IPv4, and so on. Reserved ranges are guaranteed to belong to nobody, so an accidental send causes no harm.
1. Domains and email addresses
RFC 2606 reserves top-level and second-level domains for documentation and testing. Nobody can register them, so they are safe to embed in fixtures.
| Kind | Reserved |
|---|---|
| TLD | .test / .example / .invalid / .localhost |
| Second level | example.com / example.net / example.org |
So write taro@example.com. The common mistake is test@test.com. test.com is a real, registered domain and is not reserved. The same goes for sample.com. Do not pick names that merely sound like placeholders - pick the ones a standard says are reserved.
2. IP addresses
RFC 5737 reserves three IPv4 ranges for documentation:
192.0.2.0/24(TEST-NET-1)198.51.100.0/24(TEST-NET-2)203.0.113.0/24(TEST-NET-3)
For IPv6, RFC 3849 reserves 2001:db8::/32.
These are not globally routed, so configuring one by mistake will not reach any real host. By contrast, well-known addresses such as 1.1.1.1 or 8.8.8.8 point at real services. Private ranges like 192.168.0.0/16 are also a poor choice for fixtures, because they may hit a real device on the network you are testing from.
3. Phone numbers
Japan's Ministry of Internal Affairs and Communications publishes number ranges intended for fictional use in drama and fiction. For mobile numbers these take the form 090-0000-XXXX, with a run of zeros in the middle block. Similar unused ranges exist for other prefixes.
The point is that you must not just make up digits. A random 11-digit number is very likely to belong to somebody. If your SMS test uses one, a stranger receives your notification.
Also, block the delivery path itself. Route all outbound mail in test environments to a development inbox (a mail catcher) or disable sending entirely. Safe values and blocked paths are two separate controls, and you need both.
4. Names and addresses
No standard reserves names or street addresses, so this is a policy decision.
- Names - use obviously fictional surnames such as "Test Taro" or "Sample Hanako". Randomly combining plausible given and family names guarantees a collision with someone real. You cannot prevent a real person sharing a name, but you can make it obvious on screen that the record is fake.
- Addresses - do not construct a complete real address. Attaching a made-up house number to a real city can accidentally produce a valid address, and a test of your postal-mail feature will then physically deliver. Use a clearly fictional town name, or make the house number obviously artificial.
- Card numbers - use only the test card numbers published by your payment provider. Generating your own number that satisfies the length and check digit (see what is a check digit) risks colliding with a real card.
5. Do not copy production data
The most convenient option is also the most dangerous: cloning the production database. "We mask it first" tends to fail for these reasons:
- New columns get missed. Schemas grow, so the list you compiled once is always out of date.
- Free-text fields contain personal data. Notes, remarks, and inquiry bodies cannot be judged from the column name.
- The unmasked data exists in the clear, briefly, during the copy.
The safer design is to generate test data rather than export production data. When you genuinely need production data to reproduce a defect, narrow it to a single record, set an expiry, and record who took it and when. The thing to avoid is making "copy everything to dev" the normal state.
If you need bulk placeholder text or records, our test data generator and Japanese placeholder text tool run entirely in the browser and never transmit your input.
Frequently asked questions (FAQ)
Can I use test@test.com for test email addresses?
No. test.com is a real registered domain and is not reserved for testing. RFC 2606 reserves example.com, example.net, and example.org, along with the .test, .example, .invalid, and .localhost top-level domains. Those can never be assigned to anyone, so a message sent to them by mistake will not reach a real recipient.
Can I just use random digits for phone numbers in test data?
No. A random 11-digit number very likely belongs to a real subscriber. Japan publishes number ranges intended for fictional use, where mobile numbers contain a run of zeros in the middle block. In addition, block outbound mail and SMS from test environments entirely. Safe values and a blocked delivery path are separate controls and you need both.
Is masking production data safe enough for testing?
It tends to fail in practice. Schemas grow, so the list of columns to mask goes stale; free-text fields such as remarks and inquiry bodies cannot be judged from the column name; and the unmasked data exists in the clear during the copy. As a rule, design so that production data is never exported and test data is generated instead.