This simply cannot work in many cases. It is quite unrealistic to test complex logic that is hidden behind a narrow interface completely. You are hit with the full combinatorial complexity of what is behind that interface, even if might consist of independent parts internally. If you can test these parts independently, the number of required tests is a fraction of what a black box approach requires.
Another situation is checking numerical code for correctness and accuracy. There it is extremely advantageous to have testable small functions that map to individual mathematical expressions. But these are again implementation details that need to be hidden behind interfaces.
Your first statement is exactly what I've arrived at. It's just not avoidable in general.
I have to clarify that I'm not fixated on C#. Sure, you could create a helper assembly in .NET that is a mess of essentially of disembodied functions for computing every slightly more complex function that happens to be in your program. But this breaks OOD.
In C/C++ you can't do quite the same. The best you could do there is break OOD and try to hide these global functions by using private headers (which are ugly in their own ways).
Another situation is checking numerical code for correctness and accuracy. There it is extremely advantageous to have testable small functions that map to individual mathematical expressions. But these are again implementation details that need to be hidden behind interfaces.