I found tobyink's approach the best because it would even allow to run the app for integral testing with certain parts shut-off. I don't see this any different that skipping tests from the test suite.

The question is what's in control, the tests or something external.

There may be confirmation bias here, but every time I've modified my code to add a branch to distinguish between testing and deployment, it's bitten me later. I'm even leery of using separate Catalyst configurations for testing and deployment because those differences exist (I do use those configurations and usually very productively, but they introduce a risk I'm still not completely comfortable with).

As an intermediate step between "We don't have tests for this code" and "We have great tests for this code and we've refactored the code to be simple and testable and clean", debugging sections in the code are workable. I could live with them, as long as there's a plan to replace them with something better in the near future.

You wrote about management and business priorities and you're right to mention that. Getting some working tests is better than having no working tests—but even so, I just can't convince myself to have a lot of confidence in those tests until the differences between the code running under testing and the code running when deployed are minimal.

(That's why I use very, very minimal mock objects.)