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

[Atila Neves]

On Thursday, 22 March 2018 at 12:26:14 UTC, Anton Fediushin wrote:
> On Thursday, 22 March 2018 at 10:59:56 UTC, Atila Neves wrote:
>> Blog post:
>>
>> https://atilanevesoncode.wordpress.com/
>>
>> Atila
>
> I *love* built-in unittests. Putting them right after each 
> function makes things so much easier.

If it works for you, great.

> Tests in their own file is something from 90-s. It's 2018 and I 
> want to be able to write tests anywhere I want.

You _can_ write them wherever you want. I'm not arguing for 
taking any flexibility away, I'm arguing that for most projects 
it's a bad idea, and I stated the reasons why I think that's the 
case. Feel free to disagree.

> "They increase build times" - fix compiler, not my code.

If by "fix the compiler" you mean "make it so that the compiler 
knows exactly what files need to be recompiled if I only edited 
the body of a unittest block" (which is what would be needed), 
then I don't think that'll happen any time soon.

But sure, if the compiler worked that way I'd happily advocate 
for writing unittests in the same file. But for now, I'd rather 
spend a lot less time staring at the screen for 2s waiting for my 
code to be built. That's my trade-off, and reasonable people may 
(and apparently quite obviously do) disagree.

> "version(unittest) will cause you problems if you write 
> libraries" - fix dub, not my code.

This is _not_ a dub issue. version(unittest) _will_ bite you as 
soon as you compile foo.d with -unittest because its imports will 
be parsed differently. This is one to stick in the "fix the 
compiler" column. See the link to the since-reverted Phobos PR in 
the blog.

> Built-in unittests are part of D's specification. As long as it 
> allowes to do so, I'll carry on writing unittests in my code 
> and nobody can take it from me.

Who's trying to take it from you?

Atila