Wed Oct 17 - Avoiding Code Smells by Walter Bright

[Atila Neves]

On Thursday, 1 November 2018 at 03:10:22 UTC, H. S. Teoh wrote:
> On Thu, Nov 01, 2018 at 02:45:19AM +0000, unprotected-entity 
> via Digitalmars-d-announce wrote: [...]
>> Another thing to look for, is signs of code smell. I would 
>> include in this, unit tests calling private methods (which 
>> seems to be a popular thing for D programmers to do). Some 
>> will disagree that this is a code smell, but I have yet to see 
>> a good argument for why it is not.
>
> White-box testing.
>
> In principle, I agree with you that if your unittests are doing 
> black-box testing, then they should definitely not be calling 
> private methods.
>
> However, limiting yourself to black-box testing means your 
> private functions can be arbitrarily complex

If any of your functions are arbitrarily complex, you're doing it 
wrong (if alone) or your colleagues are (because it passed code 
review).

> and yet it's not thoroughly tested.

If it's not thoroughly tested via the public API, then either 
some of the private code is useless and should be deleted, or the 
public API tests aren't good enough.

> Sometimes you really do want a unittest to ensure the private 
> method is doing what you think it's doing, and this requires 
> white-box testing.

Only when writing the private method TDD-style. After it's 
written, I'd delete any and all tests for the private code and 
rely on the public API instead. Possibly useful when debugging 
though.

> This is especially important to prevent regressions, even if it 
> seems redundant at first.  Only doing black-box testing means a 
> later code change in the private method can subtly introduce a 
> bug that's not caught by the unittest (because it cannot call a 
> private method directly to verify this).

This makes no sense to me. If the public API tests didn't catch a 
regression, then the tests are bad. End of.