Quit running foreign unittests >_<

[Steven Schveighoffer via Digitalmars-d]

On 4/29/15 7:43 AM, Dicebot wrote:
> On Wednesday, 29 April 2015 at 04:53:47 UTC, Steven Schveighoffer wrote:
>> or rdmd -main -unittest -> fail to build because the templated unit
>> test doesn't work on your code. Good luck with that.
>
> I will create an upstream PR to fix it, problem solved. Have never had a
> need to do so though, not even a single time.
>
> Also : can you please point me again what part of RBT causes compilation
> slowdowns with version(unittest)? I looked through and found only
> runtime checks.

It's runtime checks that slow down, the unit test compilation is not 
slow (although it was at one point, but that was for the proper full 
unit tests).

> And for that "move out of the aggregate" + "runtime test
> filtering" does what you want.

Move out of the aggregate makes it oh so ugly. I want my unit tests 
right where they belong.

Runtime test filtering seems like it adds more complexity to the system 
unnecessarily. All I need is a way to say "yes compiler, I want to run 
those templated unit tests I imported" or "no compiler, I don't want to 
do that". What the default is really isn't important.

>> Again, there are so many reasons I should not have to worry about unit
>> tests in my library being run with your code. That's on you. I didn't
>> write it for your code to run, if you want to run it, run my unit test
>> script.
>
> If you don't wan't to run it, filter it out in the test runner. I assure
> you, there are at least as much reasons why I shouldn't worry if you
> actually run tests for your library and how those need to be run. Both
> defaults can be circumvented.

I don't *care* if you run it. But the compiler shouldn't force you to. 
The funny thing is, you DON'T run imported non-template unit tests, 
because the compiler doesn't make you (and actually doesn't allow you 
to). So why should this be any different? A unit test is supposed to 
test the unit, not the world.

-Steve