DEV Community

Bugra Ergin
Bugra Ergin

Posted on

Your app validates emails in production but not in dev. What else are you skipping?

We all use mailpit or mailtrap in dev. Nobody sends real emails locally. That's been solved forever.

But email is the only thing we actually solved. Everything else? We just... skip it.

Email validation

In production your signup checks MX records, blocks disposable domains, all of it. In dev you type test@test.com and move on with your life.

Small problem: someone owns test.com. They receive your test data. That address shows up on 1,500+ blacklists because every developer on earth uses it.

And MX validation can't even run properly in most dev setups. The DNS lookups fail offline, they fail with fake domains. Symfony has an open issue about disabling checkMX in test environments for exactly this reason. So the one piece of validation that actually matters ships completely untested.

Remember when HBO Max sent "Integration Test Email #1" to all their subscribers? Yeah.

Regex

You know the workflow. regex101, three test strings, looks good, paste into code, commit, push. No unit test. Ever.

There's a library on GitHub called regex-tester. The whole pitch in the README is one line: "Because regular expressions are complex and error prone and you probably don't unit test them." That's it. That's the selling point. And honestly? Fair enough.

Character limits

120-char company_name column in your database. No maxlength on the form. Works great in dev because you always type "Test Company." Blows up in prod when someone pastes their full legal entity name.

Microsoft added verbose truncation warnings as a major feature in SQL Server 2019 because the old error was so useless nobody could debug it. Emojis cut SMS limits from 160 to 70 characters. Twitter's 280-char limit turned out to be a byte limit that breaks with multibyte characters. Entity Framework silently truncates without an error. This stuff is everywhere.

CORS

Locally you run frontend and backend on the same origin. Or you throw Access-Control-Allow-Origin: * on everything. Or you install that browser extension. Or you launch Chrome with --disable-web-security.

Then you deploy to real subdomains and spend your afternoon googling CORS errors that didn't exist yesterday. I've seen senior devs lose half a day on this. There's just no clean way to test real cross-origin behavior locally.

SSL

curl -k
NODE_TLS_REJECT_UNAUTHORIZED=0
verify=False
CURLOPT_SSL_VERIFYPEER => false

We've all done it. "Temporary." Then it's in the Dockerfile. Then staging. Then someone copies that config to prod and now your app trusts every cert on the planet.

So what

The Twelve-Factor App told us about dev/prod parity in 2011. We're still not doing it.

Production runs real validation, real security, real constraints. Dev runs on vibes and test@test.com. The gap between those two is where your next production bug already lives.

The mailpit pattern works for more than email. Use tools that give real results but cost nothing and stay out of your way. I built some free utility APIs for exactly this (apixies.io) but honestly it doesn't matter which tool. It matters that you stop skipping the check entirely.

If it only runs in production, it's not a check. It's a hope.

What's the dumbest prod bug you've shipped that a simple dev check would've caught?

Top comments (0)