Email and Notification Testing

Why Email and Notification Testing Matters #

Emails and notifications are critical communication channels between an application and its users. A broken password reset email means users cannot recover their accounts. A missing order confirmation erodes trust. A poorly rendered marketing email damages brand perception.

Despite their importance, email and notification testing is often overlooked because these features involve external systems and are harder to automate than UI testing.

Types of Emails to Test #

Transactional Emails #

Triggered by user actions — highest priority for testing:

Marketing Emails #

Sent to groups of users:

• Personalization tokens resolve correctly (name, preferences)
• Unsubscribe link works and is prominent
• CAN-SPAM/GDPR compliance (physical address, sender identification)
• Dynamic content renders based on user segments

System Notifications #

Automated alerts:

• Error notifications to admins
• Scheduled report emails
• Threshold alerts (disk space, API limits)

Email Testing Environment #

Tools for Capturing Test Emails #

Never send test emails to real addresses. Use email sandboxes:

Setting Up Mailhog Locally #

# Install (macOS)
brew install mailhog

# Run
mailhog

# SMTP: localhost:1025
# Web UI: http://localhost:8025

Configure your application to use localhost:1025 as the SMTP server in test environments.

What to Test in Emails #

Delivery #

• Email arrives within expected time (transactional: <30 seconds, marketing: <5 minutes)
• Email is not caught by spam filters (check spam score)
• Correct recipient (To, CC, BCC fields)
• Correct sender (From address matches expected)
• Reply-To address is correct

Content #

• Subject line is correct and personalized
• Body content matches the trigger action
• Dynamic data is correct (names, amounts, dates, order numbers)
• Links are valid and point to correct destinations
• Unsubscribe link is present and functional
• Footer contains required legal information

HTML Rendering #

Email HTML is notoriously limited compared to web HTML:

Test rendering in at least:

• Gmail (web and mobile)
• Apple Mail (macOS and iOS)
• Outlook (desktop and web)
• Yahoo Mail

Security (Transactional Emails) #

• Password reset tokens are one-time use
• Tokens expire after appropriate time (1 hour typical)
• Tokens are cryptographically secure (not sequential)
• Old tokens are invalidated when new one is requested
• Links use HTTPS
• No sensitive data exposed in email body (full credit card numbers, passwords)

Exercise: Testing a Registration and Password Reset Flow #

You are testing the email notifications for a web application’s authentication system.

Scenario 1: Registration Confirmation Email #

Scenario 2: Password Reset Email #

Scenario 3: Notification Preferences #

Push Notification Testing #

What to Test #

In-App Notification Testing #

• Notification badge count updates in real-time
• Marking notification as read decreases the count
• Notification links navigate to the correct page
• Old notifications are accessible in notification history
• Notifications appear for the correct user (multi-user testing)

Key Takeaways #

• Never use real email addresses for testing — always use email sandboxes like Mailtrap or Mailhog
• Transactional emails require security testing (token expiration, one-time use, no email enumeration)
• HTML email rendering varies dramatically across clients — test in Gmail, Outlook, and Apple Mail at minimum
• Push notifications need testing for permission flow, delivery timing, and DND mode interaction
• Always verify unsubscribe functionality and legal compliance (CAN-SPAM, GDPR)
• Test edge cases: what happens when dynamic data is missing, when emails bounce, when notifications queue