As all developers are aware, dealing with customer data necessarily involves a great amount of care. However sensitive, steps must be taken to ensure that data is held appropriately and access granted on a strictly need-to-know basis.
On the other hand, many of us are also faced with the need to run a development environment which closely matches the live state of the production environment . Generating dummy data wherever possible is of course the best solution, but in some situations it is simply not practical to do so (notably where large parts of the site are CMS driven), and without realistic sample data, edge cases are far more likely to be missed.
Reconciling these conflicting requirements can be a challenge, and you may find that in spite of your best intentions, members of your team accidentally email customers regrettably informing them of losing the game .
Clearly, all production data should be sanitized in order to prevent such blunders from occurring. Many external services such as Stripe provide sandboxed environments (and test cards ) to make such things easier, but when it comes to emails a solution can seem less clear-cut.
One answer would be to use
sink email address
such as the one provided by
. However, User data models often include a
constraint on email addresses, and so an alternative would be to simply construct a random email for each user.
Unfortunately neither of these provide visibility on the actual emails you're sending out. The best solution I've found is to take advantage of the Gmail's 'plus' aliases , also available for all Google Apps users. Sanitizing production emails using this method allows you work and test with emails, and is trivial to set up programmatically (example using Postgres):
>>> UPDATE customer SET email = 'testing+customer-' || id || '@domain.com'; # email@example.com, ...