On Sun, Dec 6, 2020 at 4:24 AM Peter C++ via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
To start with, you should not test private stuff. It is private, so it might change. Binding tests to the private parts makes them harder to change, because of the tests, that should make software easier to refactor and change. 

I agree with Peter here.
"Refactoring for testability" is definitely a thing. This generally involves at least two parts, and maybe more:
(1) Make sure all your dependencies are injected
(2) Make sure all your functionality is exposed

#2 doesn't have any catchy phrase the way #1 has "dependency injection."  But generally, if your complaint is "Class Foo's `x` method is private, but I want to test it!" then the obvious fix is to make Foo's `x` method public.  If your complaint is "My unit-testing framework requires `Foo` to have an operator<<!" then the obvious fix is to give `Foo` an operator<<. And so on.


Also, notice that if you friend a whole namespace... Namespaces, unlike classes, are open. Physically speaking, anybody in any .cpp file can add a new member to any namespace. So by friending a namespace you'd be saying "I don't really care who can access my private stuff."
Technically this is already true of `private`, because of this hack I blogged three days ago
https://quuxplusone.github.io/blog/2020/12/02/unused-private-member/
https://quuxplusone.github.io/blog/2020/12/03/steal-a-private-member/
but I consider that more of a loophole that might one day get fixed, if anyone can figure out how. I definitely wouldn't want to see WG21 put any effort toward increasing the visibility of private members.

–Arthur