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