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

[Jonathan M Davis]

On Friday, March 23, 2018 13:43:15 H. S. Teoh via Digitalmars-d-announce 
wrote:
> Yep.  As I mentioned elsewhere, recently I've had to resort to external
> testing for one of my projects, and I'm still working on that right now.
> And already, I'm seeing a liability: rather than quickly locating a
> unittest immediately following a particular function, now I have to
> remember "oh which subdirectory was it that the tests were put in? and
> which file was it that a particular test of this function was done?".
> It's an additional mental burden to have to keep doing the mapping
> between current source location <-> test code location (even if it's a
> 1-to-1 mapping), and a physical burden to have to continually open
> external files (and typing a potentially long path for them) rather than
> just "bookmark, jump to end of function, navigate unittest blocks" in
> the same file.

When I've done unit testing in C++, I've had the tests in separate files,
and when I do that, I usually put all of the test files in the same place
(e.g. include/ for the .h files, source/ for the .cpp files and tests/ for
the .h and .cpp files with the tests) and have a 1-to-1 relationship between
the .h/.cpp pair containing the code and the .h/.cpp pair containing the
tests. Also, the test functions are usually named after the function that
they're testing. So, it's all fairly organized, but it's still way more of a
pain than just having the unittest block right after the function being
tested, and it makes it easy for folks to just ignore the tests and easy for
you to miss that something wasn't tested.

Having dealt with both that and putting all of the unit tests next to stuff
in D, I find having the tests right after the functions to be _far_ more
maintainable.

In fact, in std.datetime.interval, most of the tests are outside the
templated types that they're testing in order to avoid having the tests
included in every template instantiation, and that's turned out to be _way_
more of a pain to maintain than having the tests right after the functions.
And that doesn't even involve a separate file.

Obviously, YMMV, but in my experience, having the tests _immediately_ after
what they're testing is vastly more maintainable than having the tests
elsewhere.

- Jonathan M Davis