Why think unit tests should be in their own source code hierarchy instead of side-by-side

[H. S. Teoh]

On Tue, Mar 27, 2018 at 09:27:16AM -0400, Steven Schveighoffer via Digitalmars-d-announce wrote:
> On 3/26/18 9:26 AM, Atila Neves wrote:
> > On Friday, 23 March 2018 at 14:54:57 UTC, Steven Schveighoffer wrote:
[...]
> > > It's simple. Unittests in imported modules should not be visible.
> > > They should be compiled as if -unittest was not passed.
> > > 
> > > Even Walter and Andrei are supportive:
> > > https://github.com/dlang/dmd/pull/6375#issuecomment-373487247
> > > 
> > 
> > That would completely break __traits(getUnitTests).
> 
> I'm sure we could find a way to keep the features here, 99.99% of the
> time, you don't care about, nor want to parse or semantic, an imported
> module's unit tests. Only specialized unit test frameworks care about
> this feature.
> 
> It could be as simple as, if you use __traits(getUnitTests,
> modulename) anywhere in a module, then that module is imported the
> traditional way. Or we could create a specialized "import unittest"
> syntax for this purpose.
[...]

Yeah, since __traits(getUnitTests) is inside the compiler, it could in
theory be as simple as:

	- `import abc;` - compiler lexes and parses abc, but leaves
	  unittests alone (but still present as AST nodes with no
	  semantic run). Basically, module abc is parsed as if
	  `-unittest` is not present.

	- `__traits(getUnitTests)` triggers semantic on unittest AST
	  nodes of the target module.

Does __traits(getUnitTests) work if you don't specify `-unittest`? If
so, then the solution is probably already there.


T

-- 
Written on the window of a clothing store: No shirt, no shoes, no service.