On the C# API I develop for we overcome these issues in a few ways.
1. Our way of implementing DDD helps us organize code into infrastructure and domain. Domain objects typically aren’t allowed to have external dependencies. Infrastructure code is primarily for data access and mapping. Our API code (controllers and event handlers) ties the two together.
2. Given the above we are able to write a) very clear and concise unit tests around domain objects and API endpoints and b) integration tests that don’t have to bother with anything but data and other external dependencies.
The result is that when we go to ask, “How does the system respond given X?” we can either point to a test we have already written or else add a new test or test case to cover that scenario.
We can even snapshot live data in some critical areas that we can then drive through our high level domain processes (we process payroll so it’s a lot of data to consider). If someone wants to know how a particular pay run would play out, they can just craft the data snapshot and write some assertions about the results.
We also use FluentValidation (on API objects only) and test those as well (but only if the rules are non-trivial).
1. Our way of implementing DDD helps us organize code into infrastructure and domain. Domain objects typically aren’t allowed to have external dependencies. Infrastructure code is primarily for data access and mapping. Our API code (controllers and event handlers) ties the two together.
2. Given the above we are able to write a) very clear and concise unit tests around domain objects and API endpoints and b) integration tests that don’t have to bother with anything but data and other external dependencies.
The result is that when we go to ask, “How does the system respond given X?” we can either point to a test we have already written or else add a new test or test case to cover that scenario.
We can even snapshot live data in some critical areas that we can then drive through our high level domain processes (we process payroll so it’s a lot of data to consider). If someone wants to know how a particular pay run would play out, they can just craft the data snapshot and write some assertions about the results.
We also use FluentValidation (on API objects only) and test those as well (but only if the rules are non-trivial).