I have the opinion that is the job of functional tests anyway.
Unit tests should only exercise public interfaces, with internals and private parts being tested as side effect of calling them.
Unit tests should only exercise public interfaces, with internals and private parts being tested as side effect of calling them.
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 numerical code example can be achieved with an Assembly of internal functions/methods, exposed only to the implementation and unit tests.
Of course, this is easy to do in a greenfield project from the start, not so easy on legacy code.
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).