If you plan on using separate modules, yeah, but generally you have a 2 module setup: the one that calls the external api and the one that does mocks.

Give it a try for sure. This is no new concept and it’s much more easier to reason about compared to the complex setup that mocks require.

Mocking internal logic for me is a hard no, this is one of the big reasons I try to avoid mocks whenever I can. The point of tests is to ensure correctness of your system at different levels. If you are mocking actual business logic, then you are introducing tests that can result in false positives which may cause more problems than they solve, as the code is a dynamic media that is always changing.

Mocking internal code is a huge red flag, it tells everyone that there is fundamental architectural problem, or lack of experience.

In the end, programming is all about data transformations. To put it simple: input → output

So when we test, then we want to assert that we got the expected output from the input.

With that in mind we can design our system in such a way that we only care about changing the input, that input can come from a lot of places.

I saw you mention unit testing and E2E. People tend to conflate all these terms. 99% of the time programmers write integration test, E2E test is a subset of integration test. All your Ecto test are integration test. If a function has side effects then the only way to test it is by an integration test.

Unit test requires a function without side effects.

Regardless of this pedantickery lets just agree that tests should be simple to reason about and if you feel that mocking is the right answer, then you properly have a bigger problem at hand.

That approach is also what is presented in this great talk: Boundaries

I personally like this approach quite a lot.

I don’t know anyone that would consider setting fixtures in your database to be a mock. The Ecto sandbox does not mock the database, the transaction are as real as it gets. This is what I mean about conflating terms.

Traditional when we talk mocks, then we’re talking about changing code. That is why there is and always will be so much contention around them, since they literally obfuscate what really goes on. It is far better to setup a database with fixtures or a web server with an API that you are testing again. Don’t change your implementation, but focus on changing the input.

Sadly this conversation seems to be going in circles.

It would be great if you could show an example project where mocking of internal logic can be applied and show pointers on its characteristics (even if that implementation were to be just temporary). That would certainly will solve this argument in a jiffy, as pointing to camps is not a compelling argument.