Why do private member variables behaved like protected in the same module when creating deriving class?

[Atila Neves]

On Thursday, 1 November 2018 at 17:59:35 UTC, Steven 
Schveighoffer wrote:
> On 11/1/18 10:29 AM, Atila Neves wrote:
>> On Wednesday, 31 October 2018 at 20:46:05 UTC, Zot wrote:
>>> On Monday, 29 October 2018 at 09:25:07 UTC, 
>>> unprotected-entity wrote:
>>>> Just how often does one need to access the private members 
>>>> of a class, within a module?
>>>
>>> a lot actually. e.g. unittests
>> 
>> Unit tests should go through the public interface like anyone 
>> else. All private members and functions are implementation 
>> details that shouldn't matter and shouldn't break any tests if 
>> they're all removed.
>
> So... don't test private functions?

Precisely.

Caveat: test them if you *really* want to, but be prepared to 
delete the tests with extreme prejudice.

I never do, implementation details are just that.


> I do all the time. I want to test every single function I can.

Testing to me is like going to the gym. I don't actually want to 
do it, but I do anyway because the alternative is worse. IMHO, 
tests take time to write, and testing implementation details is 
not a worthwhile use of my time.


> I also look at internals, especially when I find bugs about 
> them that can be caught with a peek at internal data.

Sure, but that's not what my point was.

> Perhaps the internals implement some protocol, and you want to 
> check it's in the right state part-way through a transaction.

If you're writing it from scratch, I'd say write a test for that 
as you're going. But then delete it after you're done.

If it's already written I'd use a debugger.

> However, I would *love* to be able to specify unit tests that 
> *can't* access private internals for testing purposes. IIRC, it 
> was proposed at some point to require this for documented 
> unittests.

I do this all the time by having the tests in a different file, 
which is what I always do now given how much trouble in-module 
unittests have been for me.