https://issues.dlang.org/show_bug.cgi?id=13454

Sobirari Muhomori <dfj1esp02@sneakemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://issues.dlang.org/sh
                   |                            |ow_bug.cgi?id=13291

--

https://issues.dlang.org/show_bug.cgi?id=13454

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@dawg.eu

--- Comment #1 from Martin Nowak <code@dawg.eu> ---
I'd say that each template instance should come with it's own unittest, but there should be a way to disable unittests for non-root modules, i.e. modules that are imported, but not part of the compilation.

--

https://issues.dlang.org/show_bug.cgi?id=13454

--- Comment #2 from Martin Nowak <code@dawg.eu> ---
Also see https://github.com/D-Programming-Language/druntime/pull/990

--

https://issues.dlang.org/show_bug.cgi?id=13454

Dicebot <public@dicebot.lv> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |public@dicebot.lv

--- Comment #3 from Dicebot <public@dicebot.lv> ---
It is illegal to build D projects with non-consistent version flags exactly for this reason. version(unittest) is no different.

--

https://issues.dlang.org/show_bug.cgi?id=13454

--- Comment #4 from Sobirari Muhomori <dfj1esp02@sneakemail.com> ---
In practice template unittests are often independent of their template instance and simply result in code duplication.

(In reply to Dicebot from comment #3)
> It is illegal to build D projects with non-consistent version flags exactly for this reason. version(unittest) is no different.

Phobos is compiled without unittests, that will prohibit user code from being compiled with unittests.

--

https://issues.dlang.org/show_bug.cgi?id=13454

Jonathan M Davis <issues.dlang@jmdavisProg.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |issues.dlang@jmdavisProg.co
                   |                            |m

--- Comment #5 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
I would argue that it only makes sense to compile in unittest blocks or version(unittest) code when directly compiling a module with -unittest and not when importing it. Otherwise, you'll end up getting stuff like Phobos' unit test code in your application when you compile it with -unittest, and the unit test code in libraries like Phobos would then potentially affect your program, causing fun problems like linker errors just because you imported a 3rd party module inside of your own module that you're unit testing.

--

https://issues.dlang.org/show_bug.cgi?id=13454

--- Comment #6 from Dicebot <public@dicebot.lv> ---
> Otherwise, you'll end up getting stuff like Phobos' unit test code in your application when you compile it with -unittest

And this is _exactly_ what I want by default.

> Phobos is compiled without unittests, that will prohibit user code from being compiled with unittests

It never uses version(unittest) in a way mentioned in the first post.

Actually I do remember major removals of version(unittest) from Phobos completely because it caused too many issues with random imports. Looking at current master there are still many though :(

--

https://issues.dlang.org/show_bug.cgi?id=13454

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #7 from Walter Bright <bugzilla@digitalmars.com> ---
When designing unit tests for templates, a decision must be made:

1. are the unit tests to be run for specified instantiations only? 2. are the unit tests to be run for all instantiations?

For (1), put them outside the template body. For (2), put the unit tests inside the template body. In the example code, the unit test code is in both places and both are expected to exist, and as you discovered, such does not work.

The solution is either put all the unit test code outside the template for
option (1), or all inside for option (2). I almost always go with (1) for my
template code, and it works fine.

> It's questionable that duplicating tests for each instantiation of a template is intended.

Right, that's the (1) or (2) decision above, and only the programmer can make
that decision.

> too many issues with random imports

-------- bad practice ----------
    version (unittest) import std.stdio;
    unittest { writeln("hello"); }

-------- better practice ---------
    unittest {
        import std.stdio;
        writeln("hello");
    }

--

https://issues.dlang.org/show_bug.cgi?id=13454

--- Comment #8 from Sobirari Muhomori <dfj1esp02@sneakemail.com> ---
(In reply to Walter Bright from comment #7)
> Right, that's the (1) or (2) decision above, and only the programmer can
> make that decision.

Is it a workaround or resolution?

--

https://issues.dlang.org/show_bug.cgi?id=13454

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com

--- Comment #9 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Walter Bright from comment #7)
> When designing unit tests for templates, a decision must be made:
> 
> 1. are the unit tests to be run for specified instantiations only? 2. are the unit tests to be run for all instantiations?
> 
> For (1), put them outside the template body. For (2), put the unit tests inside the template body. In the example code, the unit test code is in both places and both are expected to exist, and as you discovered, such does not work.

This is, inconvenient, if not downright horrid. Putting a unit test far away from the code it tests makes for some very difficult reading. It would be much more palatable if there was a way to say inside the tmeplate "here's a unit test, but it's not part of the template".

But I can't think of any good reason why unit tests should be compiled when importing. If you want to build the unit tests, build the module that contains them. The author wrote the unit tests to run when he built that module, not when someone else imported them. They probably aren't meant for other consumption.

All that being said, putting unit tests outside the template is a valid workaround, even if it sucks.

--