[danparsonson]

> I don’t think it’s worth doing that

OK; it's your choice to do what you think is right.

> and comparing it to scientific experiments doesn’t really apply.

Why not? I think it's a fairly apt comparison; you have a theory ("this piece of code does the following things"), and write tests to prove it.

> You can do all that without mocks as well.

OK, but mocks make it easier and cleaner - so why wouldn't I do that?

> Making the tests run faster at the expense of better tests seems counterproductive.

Smaller, more focused, cleaner tests are better in my opinion; speed is a beneficial side effect.

> Now you should think of reasons why you should not isolate.

Why? That's your argument - it's not on me to prove it for you. If you can give me some good reason why mocking out the interfaces you are not testing is a bad idea, and some better alternative, then we can have a discussion about it.

[mangodrunk]

I don’t want to take too much of a tangent, but in scientific studies, you are trying to understand some phenomena, and isolating variables can help with very complex things. A test is typically not that complex. Another example is the use of animals in testing medicine, it can help but it obviously would be much better to test directly on humans but we don’t for good reason.

Your position is reasonable and I do think isolation can be beneficial, but I still wouldn’t use mocking to do it.

>Smaller, more focused, cleaner tests are better in my opinion.

Cleaner is subjective. I can write “small” and “focused” functional tests that are also quick to run.

I am of the opinion that functional tests provide more value. They are testing more of the actual code than an approximation, which in turn gives a better indicator that it works. Functional tests are less likely to change unless the input/output changes.

Now let’s say you mock something in your function. Let’s say you make a change to that but the input and output are the exact same. Now you have to update your test.

[danparsonson]

> in scientific studies, you are trying to understand some phenomena, and isolating variables can help with very complex things.

Not to labour the point here, but no, the primary reason you isolate variables in a scientific experiment is that you want to ensure you're only testing the thing you intend to test. A medical study is a good example - you want to be sure that the effect you observed was due to the drug you're testing, and not some unrelated lifestyle factor.

Thanks for sharing your views on the rest; there was just one thing I wanted to expand on:

> Now let’s say you mock something in your function. Let’s say you make a change to that but the input and output are the exact same. Now you have to update your test.

I think the scenario you're describing here is: a function's dependencies have changed, but the inputs and outputs of that function have not; therefore even though the behaviour is the same, the tests still need to be updated. Is that right? In which case I would say: of course you need to update the tests - the dependencies have changed and therefore the behaviour of the function depends on different things and you need to model the behaviour of those new things in order to properly test the original function. To me this objection only holds if you are mainly focussed on code coverage; however, to me, good testing exercises the same code paths in multiple different ways to stress the code and ensure that the results are correct given all possible inputs. The dependencies of a function are also inputs of a kind.

[mangodrunk]

I appreciate your thoughtful comments but we do disagree.

>Is that right? In which case I would say: of course you need to update the tests.

That is right. I think it is bad for you to need to update a test where the input and output are the same. Your mock is there for you to essentially ignore, but now you need to update the test. You now do not know if you introduced a bug.

You are losing out on encapsulation, the test should not know about the internals, generally speaking.

>The dependencies of a function are also inputs of a kind.

Typically that should not be a concern to the caller of the function.