dotnet-testing-test-data-builder-pattern_skill

Overview

This skill is a complete guide to implementing the Test Data Builder pattern for .NET tests, showing how to create maintainable, intention-revealing test data for complex objects. It covers fluent interfaces, semantic factory methods, sensible defaults, and composing builders to reduce duplication and clarify test intent.

How this skill works

The pattern provides builders that expose With* fluent methods and semantic factory methods (e.g., AUser(), AnAdminUser()) to produce valid objects with reasonable defaults. Tests override only the properties relevant to the scenario and call Build() to get the final domain object. Builders can combine with other builders to assemble complex aggregates like orders with users and products.

When to use it

• When tests require objects with many properties and setting them inline obscures intent
• When similar object construction repeats across multiple tests
• When you need fine-grained control over test data while keeping readability
• When composing aggregates that include other domain objects
• When mapping clear scenario names (AnAdminUser, ARegularUser) improves test clarity

Best practices

• Provide sensible default values so Build() yields a valid object without extra setup
• Expose fluent With* methods and semantic factory methods for common scenarios
• Keep builders simple: avoid business logic or complex validation inside builders
• Compose builders for aggregates instead of duplicating construction logic
• Centralize reusable test data helpers (TestData.Users, TestData.Products) for shared scenarios

Example use cases

• Unit tests where only one or two properties matter (use builder defaults for the rest)
• Theory-based tests supplying multiple variant objects via MemberData
• Integration tests that assemble domain aggregates using combined builders
• Regression tests that need named scenarios like AnExpiredUser or APremiumUser
• Creating consistent seeded test fixtures shared across test suites