QA5 min read•Audience: Developers, Designers
Edge-Case Test Data
Stress-test your email layouts with realistic edge-case mock data: long names, missing fields, empty collections, and special characters.
Key Takeaways
- Always test long customer names (e.g. "Alexandria-Bartholomew Montgomery") to check for awkward line wrapping.
- Test empty arrays ([]): ensure your receipt layout has a friendly fallback message when a cart is empty.
- Test special characters (&, <, >, ", ') to verify proper HTML escaping.
- Verify missing fields to ensure default values and fallbacks render properly.
Recommended Test Scenarios#
Before deploying an email template to production, test with these 4 payloads:
- The Ideal Case: Normal string lengths, standard order items, all booleans true.
- The Extreme Length Case: Very long product names (e.g. 80+ characters), long email addresses, large financial totals.
- The Null / Empty Case: All optional variables set to
nullor""to verify your{{fallback}}and{{#if}}conditions. - The Empty Collection Case: An empty items array (
"items": []) to confirm the template does not break.
Testing Special Characters & HTML Entities#
Test inputs with punctuation that often breaks fragile email engines:
- Ampersands in company names:
"Ben & Jerry's" - Angle brackets in user comments:
"<script>alert(1)</script>"(Handlebars safely escapes this to<script>) - Quotation marks in product titles:
'24" LED Monitor' - Accented international characters:
"Renée François Müller"
Frequently Asked Questions
How do I test an empty cart or empty receipts array?
Set "items": [] in your sample JSON and verify that your {{#each items}}...{{else}}...{{/each}} fallback message renders cleanly.
Can I import real production payloads for testing?
Yes. Paste your sanitized API payload directly into the Sample Data JSON tab in the editor to reproduce production edge cases.