Leveraging generic attributes to get test-specific test data
Tailoring AutoFixture’s customizations to the need of each test can cause a lot of code to be repeated. Let’s avoid that by using generic attributes.
Practical patterns for using AutoFixture to keep .NET tests focused, reduce incidental setup, and customize test data when the scenario requires it.
AutoFixture is most useful to me when it removes details that are necessary for a test to run but irrelevant to the behavior being exercised.
I prefer tests where the values and setup written explicitly in the test are the ones that matter to the scenario. AutoFixture can construct the remaining context, generate incidental values, integrate with mocking libraries, and apply reusable customizations so that the test itself stays focused.
The articles below explore different parts of that approach: keeping the scenario visually dominant, tailoring fixture behavior when a test needs something specific, and combining AutoFixture with more realistic generated data when that improves what the test expresses.
They are not intended as a step-by-step introduction to AutoFixture. Each post starts from a concrete testing problem and looks at how AutoFixture helps keep the test code focused on what matters.
Tailoring AutoFixture’s customizations to the need of each test can cause a lot of code to be repeated. Let’s avoid that by using generic attributes.
A unit test should show what makes its scenario special. AutoFixture can provide a valid context by default so the Arrange phase only needs to describe the difference.