2 ms·
> Unless you're testing different behavior when you're testing the endpoints, what you're doing is essentially writing duplicated test code. Except the endpoin
by WalterSear 9y ago
> Unless you're testing different behavior when you're testing the endpoints, what you're doing is essentially writing duplicated test code.
Except the endpoints are a wrapper. They aren't doing anything but acting as a pass through for injection. So, you are talking about a few minutes of boilerplate that will only change when the API changes, as a small price to pay for the ability to inject your endpoint dependencies (or their stubs) without the mess and complexity of proxying.
If it's so objectionable, handle injection some other way, without the wrapper: it's not fundamental to the idea of using data contracts to ensure correct communication between modules, while keeping the edge and core integration suites modularized.
- crdoconnor 9y ago>without the mess and complexity of proxying Proxying is less of a mess and less complex than DI. It requires zero changes to your code and can be done with off the shelf tools, it will continue to work if you rewrite your endpoint in a different language and you easily can do stuff like mimic high load or flaky networks to see what happens to your system. >If it's so objectionable, handle injection some other way Why do DI at all if you're just doing it for testing purposes?