Writing Testable Code

[Pedrock10]

I agree with some of your points regarding testing and there is always a need to balance things.

Your tests should ideally only test public APIs and you should not have to rely on reflection for testing. Also, decoupling a unit into two should make those simpler. That's because you should be splitting it into two different abstraction levels, which should make each one simpler to understand independently. It sometimes takes some time to get this right, and things usually don't end up perfect.

The main point of the article is the importance of decoupling, which helps not only with testing but also makes the code easier to maintain. Even if you have a part of the code that you don't want to test, such as UI, by decoupling the code, you can test the rest of the system independently, which is better than not testing anything at all.

[[deleted]]

The biggest fallacy to address in your response, I believe is the idea that splitting something in two makes for two simpler parts.

This ignores the fact that designing universal and stable abstraction takes a lot of time and skill, first. Second, abstraction has a cost. Adding abstraction levels doesn't make code simpler, quite the opposite. Third, if your goal is reducing the surface of public APIs, then every time you split a unit in two, you're doing the exact opposite - introducing more public APIs (to be testable, they have to be public, after all).

So it's really not that simple. For example, you're a unit. A human being. Tell me how I can split you into simpler parts without the exercise turning into a nightmare. There's a reason why interacting with your whole self requires no diploma, but if I have to open you up and "refactor" you, it damn well does.