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

[H. S. Teoh]

On Fri, Mar 23, 2018 at 07:46:34PM +0000, Johan Engelen via Digitalmars-d-announce wrote:
> On Thursday, 22 March 2018 at 15:18:40 UTC, Jacob Carlborg wrote:
[...]
> > 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.
[...]

I beg to differ.  From my experience with working on Phobos, file size
or perceived "clutter" simply isn't an issue.  Good chunks of Phobos
have long lists of unittests following an overload set, and often even
interspersed between overload sets, and we have never shied away from
adding more unittests to the list as bug fixes get added, nor have we
ever felt the pressure to move the unittests elsewhere.

Using a code editor with modern capabilities helps to a great degree, of
course.  If your primary way of navigating a source file is by paging
up/down or by pulling a scrollbar, IMO you're doing it wrong.  You
should rather be using actually useful navigation, like Vim's search /
fold / jump to matching brace/parenthesis / jump to bookmark / ctags +
jump to tag, etc., or whatever a GUI IDE's equivalents of these are.
Dragging scrollbars around is so 90's, and simply isn't up to task for
navigating and working with large files.

In my own projects, I regularly deal with 3000-line source files, and
the size of the file has never been an issue as far as navigation is
concerned.  Of course, there are other considerations as to why stuffing
everything in one file might not be such a good idea, such as
encapsulation, but certainly I have never been deterred because of the
fear that adding unittests might make a file "too big".  When I do split
a file into multiple modules, it's purely for encapsulation reasons
rather than file size considerations.  In fact, I prefer to keep related
code, e.g. code + unittest for that code, together in the same file,
because otherwise things tend to go out-of-sync.  It's always easier to
put related things together in one place, rather than scatter them
across multiple places and then have to worry about keeping each piece
in sync with the others.  If a well-encapsulated module contains 1000
lines of code and 5000 lines of unittests, then so much the better.

But of course, YMMV.


T

-- 
What did the alien say to Schubert? "Take me to your lieder."