• d-bugmail puremagic.com (45/45) Dec 08 2020 https://issues.dlang.org/show_bug.cgi?id=21462

d-bugmail puremagic.com writes:

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

          Issue ID: 21462
           Summary: Unittests with visibility
           Product: D
           Version: D2
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: dmd
          Assignee: nobody puremagic.com
          Reporter: qs.il.paperinik gmail.com

PROBLEM: Most unit tests for a function are next to that function in the same
module. This means that a unit test might succeed, but the same code wouldn't
compile at usage side because of visibility issues: being in the same module, a
unit test always has access to private, package, and protected members.

SOLUTION: Allow unit tests to state a VisibilityAttribute [1] after the
`unittest` keyword. If none is specified, it is the same as public.

GRAMMAR:
UnitTest:
    unittest VisibilityAttribute[opt] BlockStatement

SEMANTICS: A unit test only has access to members that have the specified
visibility or are "more visible" (in the sense that private members are the
least visible). To e.g. test private functions, one would need to state the
unit test as `unittest private` necessarily.

CONSEQUENCES: This means that a non-private unit test usually must import the
module it is in. This can be avoided if this is done implicitly which is almost
always the right thing to do.
The auto-generated import should be omitted if the unit tests first statement
is an ImportDeclaration that imports the module or a package it is in.
Still, the unit test might need to import other modules or packages globally
imported by the module it is in, except public imports.

Documentation for unittest VA, unless VA is `public` should have added a
comment that this code will only work at a specific context. The text should be
specific for every possible VA.
The documentation generator should include the auto-generated import.

BREAKAGE:
Since some existing unit tests would need to either explicitly state `unittest
private` or import some modules to compile.

Not breaking code (setting the default visibility to `private`) would probably
lead to unit tests not being improved in practice. No code is broken silently.
Tests are fixed importing relevant stuff or stating `private` explicitly.

[1] https://dlang.org/spec/attribute.html#visibility_attributes

--