3 ms·
I solved this with a test helper method that creates a fully mocked instance and returns a struct with the mocked instance and all the mocks that it consumes. U
by infogulch 5y ago
I solved this with a test helper method that creates a fully mocked instance and returns a struct with the mocked instance and all the mocks that it consumes. Unit test setup starts by getting a new instance and overriding the mocks that it cares about. Now constructor breakage is isolated to fixing the default mocks in the helper method.
Maybe I should write this up somewhere.
- spaetzleesser 5y agoI did that too and it should be the default. Constructor injection is a bad pattern.
- infogulch 5y agoWhat do you mean by "constructor injection"?
- spaetzleesser 5y agoIn .NET a lot of DI is done by adding another interface to the constructor. So if you need some service way down the stack you add it to the constructor. This then in turn can require adding this dependency to all the tests that use this service.
- infogulch 5y agoMy comment describes a way to organize unit tests to work around this issue.
- Van-Dame 5y agoComments like these really amaze me. What sort of competent editor cannot handle such simple refactorings?
- hackerfromthefu 5y agoMaybe but in Blazor you have the choice of Property or Constructor DI. This choice is in all the major DI container libraries I've worked with in .NET, around a dozen over the years.
- DeathArrow 5y ago>Maybe I should write this up somewhere. Please do, as it sounds interesting.