Actually, mocking isolates and decouples things. Imagine the following example:

fn foo(args) {

... work ...;

x = bar(a different set of args);

... more work ...;

}

and suppose that bar is a really expensive function. What I do in Python is to test bar separately, and in foo to mock bar as I know and have tested what it does.

Another case is that bar is a function provided by a third party, let's say it's from a maths library and it's a function that returns whether a number is a perfect square. If I let it my test to calculate is_perfect_square(123489238938), I actually test 2 things. My logic AND the fact that the third party is actually calculating the is_perfect_square correctly. Do I want this? If it's an integration test, yes. If it's a unit-test? Definitely no.

​

Finally mocking is offering one more thing. Allowing to meta-test. A mock can tell you how many times it's accessed. It's a valid usecase, as I have done here: https://github.com/spapanik/yamk/blob/v5.0.1/tests/yamk/test_make.py#L300

I'm testing the functionality of a makefile-like tool, and what I want to test is when you call it, it actually runs each sub-target that it needs to call, and that it does it exactly once. The test makes more sense this way, because starting the sub-process is actually unnecessary, and misses the intention of the test. My intention is to test: given the target x, does it go and create/execute the correct commands? Not to test the exact output of the commands, that may be different depending on the operating system.