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

[H. S. Teoh]

On Thu, Nov 01, 2018 at 01:59:35PM -0400, Steven Schveighoffer via Digitalmars-d wrote:
> On 11/1/18 10:29 AM, Atila Neves wrote:
[...]
> > 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? I do all the time. I want to test
> every single function I can.

Exactly.  There's value to white-box testing. For one thing, it allows
you to guard yourself against regressions in implementation details that
would otherwise be hard or infeasible to test from outside.

But black-box testing is also needed, e.g., to specify expected external
behaviours that should not break when the implementation details change.

IMO, we should have both.


[...]
> 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.
[...]

That's a good idea.  Nothing is worse than documentation that references
private members, that you copy-n-paste only to find that you can't write
the code that way.

Also, for proper black-box testing, it would be nice to have the
assurance that it's actually specifying outside-observable behaviour
rather than implementation details.

The two seem related, though.  If a unittest test tests outside
behaviour, chances are it should be a ddoc'd unittest too, so that users
know what the expected outside behaviour is.  Perhaps it makes sense to
conflate the two, so you could specify a black-box test just by
attaching a ddoc comment to it.


T

-- 
Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis