> I'm fully convinced mocking is a code smell of a bad implementation. In my ideal world, I can divide code into 2 different types: IO and pure logic. In test

> I'm fully convinced mocking is a code smell of a bad implementation. In my ideal world, I can divide code into 2 different types: IO and pure logic. In testing I will ignore IO almost completely and put all my focus on testing the logic. What this approach fails to cover adequately (for me at least) is when you have high-level operations/behaviours you want to test which depends on conditionally nested IO and logic. IO this, check result. If not IO that, check other result, and so on. At that point you either don’t test, you write slow E2E tests which lacks type-safety… or you mock. Granted in a deeply DI-based code-base that can often lead to 70% of the test-code being just preparing the mocks. And whenever your class gets a new dependency, it breaks all your tests. It’s not good. But what other options do we have?