[alecbenzer]

> Loosely coupled code is also easier to reason about and easier to refactor.

Can you expand more on this? I think this is where the author would disagree.

E.g., how is the code easier to reason about or refactor having introduced a location service interface that has only one one implementation?

[projektfu]

Suppose you have a unit that makes a couple of api calls to set itself up, then performs a computation, then does some sort of storage. Thinking about how you would test this might lead you to an inversion of control approach, and you might isolate side effects. The storage provider might get passed in, both to make it easy to mock, and to reduce coupling and surprise.

[alecbenzer]

I meant expand on how those things make code easier to understand, not why unit testing causes you to adopt them.

[projektfu]

Mainly it reduces surprise. If you call an interface with implicit dependencies, you won’t know if why it’s breaking without debugging and making sure it sets up its dependencies properly. If you call a testable interface with explicit dependencies, you can mock out those dependencies to debug parts individually.