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.
