Use Verify for snapshot testing in .NET. Approve API surfaces, HTTP responses, rendered emails, and serialized outputs. Detect unintended changes through human-reviewed baseline files.

Snapshot Testing with Verify When to Use This Skill Use snapshot testing when: Verifying rendered output (HTML emails, reports, generated code) Approving public API surfaces for breaking change detection Testing HTTP response bodies and headers Validating serialization output Catching unintended changes in complex objects What is Snapshot Testing? Snapshot testing captures output and compares it against a human approved baseline: 1. First run : Test generates a .received. file with actual output 2. Human review : Developer approves it, creating a .verified. file 3. Subsequent runs : Test compares output against .verified. file 4. Changes detected : Test fails, diff tool shows differences for review This catches unintended changes while allowing intentional changes through explicit approval. Installation Add Verify Package Configure ModuleInitializer Create a ModuleInitializer.cs in your test project: Basic Usage Simple Object Verification Creates VerifyUserDto.verified.txt : String/HTML Verification Creates VerifyRenderedEmail.verified.html viewable in browser. Email Template Testing Use Verify to catch unintended changes in rendered email templates: Benefits for email testing: Catches CSS/layout regressions Detects broken template variables Visual review in diff tool Version control tracks email changes API Surface Approval Prevent accidental breaking changes to public APIs: Or use the dedicated ApiApprover package: Creates .verified.txt with full API surface any change requires explicit approval. HTTP Response Testing Scrubbing Dynamic Values Handle timestamps, GUIDs, and other dynamic content: Output: Global Scrubbing Configure in ModuleInitializer : File Organization Recommended Structure .gitignore .gitattributes CI/CD Integration Fail on Missing Verified Files GitHub Actions When to Use Snapshot Testing Scenario Use Snapshot Testing? Why Rendered HTML/emails Yes Catches visual regressions API surfaces Yes Prevents accidental breaks Serialization output Yes Validates wire format Complex object graphs Yes Easier than manual assertions Simple value checks No Use regular assertions Business logic No Use explicit assertions Performance tests No Use benchmarks Best Practices DO DON'T Integration with MJML Email Testing See the aspnetcore/transactional emails skill for the complete pattern: 1. MJML templates with {{variable}} placeholders 2. Render to HTML with test data 3. Snapshot test the rendered output 4. Review changes in diff tool before approving This catches: Broken variable substitution CSS/layout regressions Email client compatibility issues Unintended content changes Resources Verify GitHub : https://github.com/VerifyTests/Verify Verify.Xunit : https://github.com/VerifyTests/Verify.Xunit ApiApprover : https://github.com/JakeGinnivan/ApiApprover DiffPlex Integration : https://github.com/VerifyTests/Verify.DiffPlex

snapshot-testing