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

[Steven Schveighoffer]

On 3/23/18 3:46 PM, Johan Engelen wrote:
> On Thursday, 22 March 2018 at 15:18:40 UTC, Jacob Carlborg wrote:
>> On Thursday, 22 March 2018 at 11:00:31 UTC, Atila Neves wrote:
>>
>>> Direct link:
>>>
>>> https://atilanevesoncode.wordpress.com/2018/03/22/keep-d-unittests-separated-from-production-code/ 
>>>
>>
>> I completely agree. Although my reason is mostly because there will be 
>> too much code in a single file if the regular code and unit tests are 
>> mixed in the same file.
> 
> Fully agree with this "too much code in a single file" point. I am 
> confident that part of the reason of Phobos unittesting being very 
> incomplete, is that adding unittests further clutters the codebase.
> Moving all unittests to the bottom of the file (pulling them out of 
> classes too) would resolve this issue in part.

Note that a frequent complaint of std.datetime (at least when it was one 
module) is that the file was too big. While it does hold a lot of 
functionality, the majority of the file size is unittests. This means 
that it can be hard to surf the file for functionality.

But on the flip side, there aren't a lot of datetime bugs!

I personally believe that there should be unit tests for every function, 
and be right next to the function. I don't want to go on a search for 
such things, or have to rely on manual documentation to know what is 
testing what. It would be nice to have your editor hide the unit tests 
unless you want to work on them.

I've worked on a project where the testing was separated from the code, 
and it was a liability IMO. Things would get missed and not tested properly.

-Steve