DEV Community

Nico Reyes
Nico Reyes

Posted on

My Python tests passed. Production still broke.

#python #testing #beginners #programming

Spent 2 hours writing tests for a data validation function. All green. Deployed to production. Broke immediately.

What went wrong

Had a function that validated user input from a form:

def validate_email(email):
    if '@' in email and '.' in email:
        return True
    return False
Enter fullscreen mode Exit fullscreen mode

Wrote tests:

def test_valid_email():
    assert validate_email('[email protected]') == True

def test_invalid_email():
    assert validate_email('notanemail') == False
Enter fullscreen mode Exit fullscreen mode

Tests passed. Felt good.

Production users started entering stuff like user@domain (no TLD), @domain.com (no username), user.name@ (incomplete). All passed validation. Database filled with garbage emails. Had to roll back.

The actual problem

Testing happy path is easy. Testing edge cases takes actual thought.

My tests only checked "does it have @ and ." - never tested WHERE those characters are, or if the format makes sense.

What I changed

Ended up using email-validator library instead of rolling my own:

from email_validator import validate_email, EmailNotValidError

def validate_email_input(email):
    try:
        valid = validate_email(email)
        return True
    except EmailNotValidError:
        return False
Enter fullscreen mode Exit fullscreen mode

Still wrote tests, but now they cover weird inputs:

def test_missing_username():
    assert validate_email_input('@domain.com') == False

def test_missing_domain():
    assert validate_email_input('user@') == False

def test_spaces_in_email():
    assert validate_email_input('user [email protected]') == False

def test_valid_email():
    assert validate_email_input('[email protected]') == True
Enter fullscreen mode Exit fullscreen mode

Took like 15 min to add these cases. Would've saved me the rollback.

Lessons I keep relearning

Test the weird stuff - Users will always find ways to break your assumptions. Test empty strings, null values, special characters, unicode, really long inputs.

Don't reinvent validation - Email, phone, URL, credit card... libraries exist for a reason. They've seen all the edge cases already.

Production data is messier than test data - Your test suite uses clean examples. Real users paste from Excel, autocomplete forms wrong, or just fat-finger stuff.

Coverage ≠ quality - 100% coverage means nothing if you're only testing happy paths. One real edge case test beats ten generic ones.

Still working on this honestly. Keep catching myself writing tests that "feel complete" but miss obvious edge cases until production proves otherwise.

Top comments (0)