that feels pretty dismissive / reductive to me... seems like you're all saying that var actual = calculator.GetSolarTimes(new Date(...), new Location(...));

that feels pretty dismissive / reductive to me... seems like you're all saying that var actual = calculator.GetSolarTimes(new Date(...), new Location(...)); is JUST SIMPLER and better than public async Task<SolarTimes> GetSolarTimesAsync(DateTimeOffset date) with an internal location provider as a dependency because it's easier to test. but i think that ignores the reason why DI containers were invented in the first place and assumes that the solar calculator is just a simple entrypoint-type application, rather than being a component in real application. You might have 20 layers of THING, somewhere inside which, this solar time calculator lives and is used... and you still have to get Location from SOMEWHERE to pass it into the calculator. so what happens when Whatever uses the location provider to get the location and pass it along needs to be tested? and through how many layers of stack do you need to pass Location before you realize that every test of every intermediate layer needs to know about location, but only for the purpose of passing it along? I think it's a more nuanced case than you're making it seem. Beyond some level of complexity in an application, it becomes simpler to co-locate dependencies where they're actually used.