[CuriouslyC]

Mocks are a contentious topic as you've probably guessed. In my opinion they're a sign of coupled code, you should be able to hit very high coverage without a single mock, but if you're a dev in an org that tracks code coverage you'll probably end up writing a fair number of them since the odds are high you'll be consuming coupled code.

[jerrygenser]

If you have a dependency like a third party API (or even internal code), and you write an API client, then depend on that client, would it be considered couple code?

In such cases, if I am using dependency injection and creating a (stub?) versions of that client which returns a hardcoded or configured output, would that be considered a mock? OR would this be OK and not "coupled"?

[aleksiy123]

I think mocking with DI makes perfect sense.

Most people will say something like for unit tests you should test your functions by passing the state as parameters to test. I'm going to call this "outside in" loose coupling.

Mocking is for the inverse. When you want to test a unit of code that is calling some other outside unit code. Its really not any different just "inside out".

So imo with DI you gain loose coupling through dependency inversion. But because of dependency inversion you need to mock instead of passing state as params.

So I think if you are injecting a mocked stub this is still loose coupling because you are testing against its interface.

You're still passing state through your test but its coming from inside instead of outside, hence the mock.

Another way I have thought about this is: framework (framework calls you) vs library (you call library).

Frameworks naturally lend themselves to a more mock way of testing. Library lends itself to a more traditional way of testing.

Testing something that accepts a callback is also essentially a mock.

I hope that thought made sense.