>Sure, and the effect of doing those things is moving data around. What does your program do with the results of these side-effects? Does it parse it? Transform it in any way? Decide whether to run effect A next with the result or effect B? This is the code that, if extracted, can be tested in isolation of databases and HTTP servers.
It's very frequent that this "decision making/calculation" code:
* Doesn't do very much.
* Isn't even in the top 5 source of bugs for your app.
* Integration tests caught those bugs just fine anyway.
* The process of extraction balloons the size of the code base (all those yummy extra layers of indirection), sometimes introducing fun bugs.
It's certainly the right thing to do if you have a self contained chunk of complex decision making/calculation code (e.g. a parser or pricing engine).
However, if you do this as a matter of principle (and far too many do) then this advice isn't just wrong, it's dangerously wrong.
Be careful. Principled application of this advice can lead to separation of concerns. Programs that are broken down into independently verifiable modules can lead to an abundance of spare time and pursuit of new features in the absence of errors. Ensure your job security by making sure that it is difficult to test your code.
In all seriousness though it's smart to take a layered approach to testing. It is plain good engineering to be able to separate your program's concerns into independent, verifiable modules and to isolate side-effects from pure code. Definitely write a few integration tests to verify that the modules work together and that global properties like configuration have the desired behaviours. And by jolly live dangerously and test in production!
But don't do it dangerously. Make sure you have the right team and infrastructure to test in production safely without taking down production or frustrating customers. But test in production for reals. Integration tests are fine but nothing compares to prod. Not mocks, synthetic inputs, simulated environments, and not good intentions.
It's very frequent that this "decision making/calculation" code:
* Doesn't do very much.
* Isn't even in the top 5 source of bugs for your app.
* Integration tests caught those bugs just fine anyway.
* The process of extraction balloons the size of the code base (all those yummy extra layers of indirection), sometimes introducing fun bugs.
It's certainly the right thing to do if you have a self contained chunk of complex decision making/calculation code (e.g. a parser or pricing engine).
However, if you do this as a matter of principle (and far too many do) then this advice isn't just wrong, it's dangerously wrong.