[Issue 21462] Unittests with visibility

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=21462

--- Comment #2 from Bolpat <qs.il.paperinik at gmail.com> ---
(In reply to Mathias LANG from comment #1)
> All things considered, this sounds like a good addition to DScanner.

I should have a look at DScanner.

> If one wants unittest to only test a certain visibility level, one may place
> the unittest in a different module. Conventions may arise (Tango used
> `modname_test.d` IIRC). Adding a language feature for this use case seems a
> bit too much.

People like to have their unittests next to the function. Even in aggregate
templates, people jump through hoops and hurdles to get there. Documentation
generation is the primary reason, but not the only one. Maintainability is
another.

> Additionally, it would most likely "get in the way" of most unittests. The
> point of a unittest is to be a conformance test at the lowest level.

That is the point of *some* unittests. Those would be private unittests.

> Hence, it is normal for unittests to test internals of a data type, private members or functions, etc...

Depends on how you define normal, I guess. Unittests also make sure a function
can actually be used (from outside the module/package, of course) the way it
was intended to.

> Going back to the problem, the root of your reasoning is that the unittest
> would not compile at usage site. But the only unittests that should likely
> compile outside of the module are *documented unittests*.
> 
> Introducing a check that only non-private members are called in a documented
> unittest *might* work, but some people (like myself) are writing documented
> unittests even for internal helpers, so it should be possible to opt-out (or
> be opt-in).

A possible solution would be: By default, if the unittest is documented, it is
a public unittest and private otherwise. You can put `private` on a documented
unittest and `public` on an undocumented one to override the default, of
course. In an OOP environment, you’d maybe like to make sure a derived class
can make use of the protected members as intended and a `protected` unittest
could demonstrate that.

I just don’t like the idea that semantics of the unittest depend on a
(documentation) comment.

--