Lookahead in unittest

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, May 12, 2017 14:46:30 H. S. Teoh via Digitalmars-d-learn wrote:
> On Fri, May 12, 2017 at 05:23:23PM -0400, Steven Schveighoffer via
> Digitalmars-d-learn wrote: [...]
>
> > Note, you can achieve what you want with version(unittest):
> >
> > version(unittest)
> > {
> >
> >    class A { B b; }
> >    class B { }
> >
> > }
> >
> > unittest
> > {
> >
> >    // use A and B here
> >
> > }
>
> [...]
>
> This advice, unfortunately, needs to be tempered with caution about
> namespace pollution and accidental dependency of things outside
> unittests on things inside a version(unittest) block.  There's also the
> issue of library code introducing extraneous import dependencies that
> are really only necessary for unittesting, but get pulled in anyway
> because user code happens to compile with -unittest.

Yeah, that can get annoying, though I think that the only real problem in
general is imports. If you use version(unittest) on imports, then you run
the risk of having imports that are required for normal operation being only
available when you compile with -unittest and not catching it. But unless
you have a problem using version(unittest) types or functions in your actual
code (which would be kind of weird), then I wouldn't expect it to be a
problem.

However, in many cases, it makes sense to just move the declarations into
the unittest blocks (especally if they're only used in one unittest block),
and then you avoid the whole problem (though in this case, you'd want to
mark the classes as static if you put them in the unittest block).

- Jonathan M Davis