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
