always use .test TLD for email domain names

[armadillojim]

Hello! Thank you for the wonderful testing library.

I have a domain name that uses my last name, and I frequently get test emails from developers' staging environments. This is endlessly annoying to me, and it potentially exposes companies' internal data when testing.

When I alert companies to this, they often thank me for telling them, but they are often clueless as to how such a thing happened. However, last month GitLab sent me a test email, and I when I alerted them, they were kind enough to ask their engineering team for the cause. It turns out they use ffaker to generate fake email addresses to test with. I can only imagine that many other companies do the same.

Would you be willing to change ffaker so that fake email addresses always use the .test TLD? Perhaps throw in .example and .local if you want variety.

I've created a PR here with one possible fix. I'm open to suggestions and feedback, and am willing to change my proposal.

[Volosh1n]

Hi @armadillojim! Thank you for this suggestion and sorry to hear that you got annoyed by those emails, but there are two things I'd like to say:

1. There is a FFaker::Internet.safe_email, which always generates emails with @example.com
2. Staging envs should have email intercepting or something like MailCatcher to avoid such trouble. Not to be rude to those projects, who don't understand this, but anyway...

[armadillojim]

Thanks!

I agree the use of the library ultimately is the responsibility of the developer. However, I feel that the library should be set up in such a way that by default it doesn't encourage harmful behavior.

What about adding a parameter to domain_name so that by default it adds .test? That way, any developer who wants to can easily turn it off (and generate potentially valid email addresses), but a hapless developer who doesn't know better will be protected.

[Volosh1n]

Yes, I agree, but I believe such approach would be dublication of purpose of FFaker::Internet.safe_email, which would be meaningless if common email generation creates non-existent emails.

[armadillojim]

Ok, thanks!

What about renaming safe_email as email, and renaming email as unsafe_email?

[Volosh1n]

Hard to tell if it's ok for those people. who already use these methods... We should create warnings for them for the next version about method name deprecation, and then rename methods for the following versions. Not a huge fun of such things. @marocchino, what do you think?

[marocchino]

@Volosh1n 🤔 How about support rails like config file? Version 2 was released six years ago, so it seems like the major release time has come.

[Volosh1n]

@marocchino sounds good, if there are plenty of things to be updated!

[marocchino]

@Volosh1n I opened discuss for it. #486 any feedback is welcomed. 😉