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

[H. S. Teoh]

On Thu, Mar 22, 2018 at 05:21:41PM +0000, Atila Neves via Digitalmars-d-announce wrote:
> On Thursday, 22 March 2018 at 16:30:37 UTC, H. S. Teoh wrote:
[...]
> > being tested, was a big slowdown for me.  I have to stop to think
> > about which subdirectory under test/ I should put the relevant
> > file(s), or if there's already a test there I have to stop to think
> > about which filename I saved it under, etc..  It's just yet another
> > mental hurdle to jump over while my already-busy brain is thinking
> > about the code itself.
> 
> Then I'd recommend:
> 
> 1) To write the tests inline when the mental burden is high
> 2) Move them afterwards when one's brain can think of where to place
> them.

I don't like having to move code around after it's written.  Besides,
since all sufficiently complex (i.e., sufficiently interesting) code
inevitably has bugs, the set of unittests following each function is
likely to keep growing, so I'd like to keep them all in one place where
possible.

But at the end of the day, it really comes down to just personal
preferences. The case could be equally argued both ways.


[...]
> > 2) Compilation times: perhaps if your unittests are too heavy,
> > compilation times could become a problem,
> 
> Maybe I wasn't clear in what I wrote: I'm not saying that I notice the
> increase in compilation times of the tests themselves. I probably
> haven't but I'd have to measure to know for sure. I'm saying that if
> you change anything in a D module, it must be assumed that any other
> module that imports the module you just edited, even if transitively,
> must be recompiled. So if I edit a test in D, under normal
> circumstances, I _have_ to recompile several files. It's not the
> unittest itself that is heavy, it's recompiling everyone who depends
> on the module that said unittest happens to find itself in.

Ah, I see your point.  So the idea is to split off the unittests into a
separate file that isn't among the dependencies, so that changing
unittests won't force everything else to recompile.  Makes sense to me.
Though I have yet to work with a project large enough where this would
cause a significant degradation in compilation times.

(Having said that, though, I find the building with dub in general is
extremely slow due to all the other stuff that it does besides building
the code.  So if the addition of a few more modules to recompile causes
a noticeable slowdown in dub, I wouldn't be surprised.)


> > but IME, they haven't been.
> 
> IME most other people find it bizarre I get angry at 2s incremental
> rebuild times. Anything over 100ms is an eternity.

Haha... well, then maybe you could help us reduce the compilation cost
of certain common Phobos modules, like std.format. ;-)  I *love*
std.format for its functionality, and use it almost everywhere in my
code, but recently I've been rather disappointed at the huge slowdowns
it adds to my compilation times. :-(  I wish the cost of using
std.format is more proportional to how much of it I'm actually using.
Currently, even something as trivial as format("%s",str) adds a
significant hit to compilation times, even though conceptually it should
really just be a single call to output a string.


[...]
> > As for the dub-specific problems introduced by version(unittest):
> > IMO that's a flaw in dub.
> 
> It's not dub-specific at all. It's same problem that you reference in:
> 
> > I remember that in Phobos we used to merge PRs containing code
> > that compiles fine with -unittest, but in real-world code doesn't
> > compile because it has stuff outside unittests that depend on
> > imports/declarations inside version(unittest).
> 
> I used dub as an example. Anyone else would have the same problems if
> they hand-wrote Makefiles using git submodules as dependencies.
[...]

True.  That's why I'm inclined to say version(unittest) is an
antipattern.


T

-- 
The trouble with TCP jokes is that it's like hearing the same joke over and over.