Stop using test@test.com to test your application

Implications of sending test data to an unknown third party, and what you should do instead

So you’ve finished coding your web application. It’s built, containerised and pushed out to your shiny new test environment for manual end to end testing. You fire up your web browser, navigate to https://my-web-application.test and start throwing some test data at it. May you create a test account

Maybe your app needs bank details, that’s ok just put some test data in there too

Maybe you ask your colleague to test it for you. You send them the link to the test application and tell them to log in with your test account and just play around with it. Maybe they use randomly generated mock data, or maybe they just put their own name and address in. I mean after all it’s only your test environment right, so it won’t do any harm if they just put in their own address.

This is great, until either by accident or oversight your test application sends out an email to the account you registered as: test@test.com

Suddenly you have to think...

Where did that email actually go?

Test.com is a real company and test@test.com is a real email address. Your “test” system has just emailed potentially personally identifiable information to an external company you have no relationship with.

At best this will annoy the owners of test.com (they most likely get spammed by thousands of test emails per day). But at worst you can cause a breach of sensitive data.

In the EU we have the General Data Protection Regulation which defines personal data as

any information relating to an identified or identifiable natural person; an identifiable natural person is one who can be identified, directly or indirectly gdpr.eu

The crucial thing to remember about GDPR is it is not just customer data the regulation protects, but also the personal information of you and your colleagues.

If you have built a system that can send emails, and somebody else to test it by entering their own personal information then, for companies operating in the EU, your company has a responsibility to keep that information secure and must not share it with a third party without a valid reason for doing so - test.com is a third party.

Other jurisdictions outside of the EU have similar data protection laws. And besides the fact of whether it is legal or not, exposing any kind of personal information in this way is just a generally terrible practise.

So what should you do instead?

Use a Mailbox you control

Of course, the best practise is to use a mailbox you control for all testing. A good trick I've seen used a lot is to abuse the plus (+) symbol in your email address. Many email providers (most notably Gmail) will ignore anything after the plus, so you can have yourname+one@gmail.com and yourname+two@gmail.com as two seperate emails in your application, but the email will all go to yourname@gmail.com

But what you don't even have a mailbox or can't use it? The second best practise is to put a procedure in place, or build tooling, to ensure your test systems are not emailing data out. But there is a third option and it's one many of you reading this will already be screaming at me. There is actually a domain name designed specifically for this purpose and that domain is example.com.

Use example.com instead

example.com, example.net, example.org, and example.edu are reserved by the IETF for use in documentation, and have been since 1999. When in doubt, and if you absolutely must use an emailbox you don’t have control over for testing, then it is better to fall back to something@example.com. You can try sending an email to something@example.com if you like, it will not be sent. The MX record for example.com does not exist so the email will not be delivered. Equally, if somebody tries to visit the site they will see this message.