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

[Jonathan M Davis]

On Thursday, March 22, 2018 16:54:18 Anton Fediushin via Digitalmars-d-
announce wrote:
> On Thursday, 22 March 2018 at 16:30:37 UTC, H. S. Teoh wrote:
> > As for the dub-specific problems introduced by
> > version(unittest): IMO that's a flaw in dub.  I should not need
> > to contort my code just to accomodate some flaw in dub.  Having
> > said that, though, I do agree that version(unittest) itself is
> > a bad idea, so code written the way I recommend would not have
> > this problem even given dub's flaws.
>
> There's no "dub-specific problems". Article is wrong about that:
> when you run `dub test` only package you are working with is
> compiled with '-unittest' option. This way it is _impossible_ to
> have any kind of problems with `version(unittest)` if you are
> writing libraries

I could be wrong, but I am _quite_ sure that dub builds all dependencies
with their test targets when you build your project with its test target. I
was forced to work around that with dxml by adding a version identifier
specifically for dxml's tests _and_ create a test target specifically for
dxml. Simply adding a dxml-specific version identifier to its test target
was not enough, because any project which depended on dxml ended up with the
dxml-specific version identifier defined when its tests were built, because
dub was building dxml's test target and not its debug or release target. The
only way I found around the problem was to create a target specific to dxml
for building its unit tests and define the version identifier for that
target only.

I had to add this to dub.json

    "buildTypes":
    {
        "doTests":
        {
            "buildOptions": ["unittests", "debugMode", "debugInfo"],
            "versions": ["dxmlTests"]
        },
        "doCov":
        {
            "buildOptions": ["unittests", "debugMode", "debugInfo",
                             "coverage"],
            "versions": ["dxmlTests"]
        }
    }

And then I have scripts such as

test.sh
=======
#!/bin/sh

dub test --build=doTests
=======

to run the tests. I had to actively work around dub and what it does with
unit tests in order to not have all of dxml's tests compiled into any
project which had dxml as a dependency.

- Jonathan M Davis