Quit running foreign unittests >_<

[Dicebot via Digitalmars-d]

On Tuesday, 28 April 2015 at 21:28:09 UTC, Steven Schveighoffer 
wrote:
> I think by default, nobody wants to test already-tested code in 
> their application. That's not the point of unit tests.

How many more times should I repeat that I am exactly that nobody?

I do want do test everything as part of my app tests, including 
all possible dependencies, transitively. This is awesome default. 
With a simple `rdmd -main -unittest` call I can ensure that 
certain app/module works correctly without having to trust 
maintainers of dependencies to run tests regularly and without 
even knowing what those dependencies are. It is beautiful in its 
simplicity which makes it good default.

> struct S(T)
> {
>   unittest {...}
> }
>
> unittest
> {
>    S!int; // run unit tests for int
> }

If this a very slow test (and there are expected many S) simply 
put the test blocks out of the aggregate.

> Now, if I want to run unit tests for S!MyCustomType, that makes 
> sense. The library didn't test that. Which is why there should 
> be a way to do it (if it's valid!).

There is something fundamentally broken with a template that 
needs to be tested for each new user type argument. Built-in 
tests must cover all possible type classes or they are incomplete.

>> Unless compiling some specific tests causes some proven 
>> _compilation_
>> slowdown (I have yet to see that) those all must be compiled 
>> and
>> filtered by runtime test runner optionally.
>
> For example, RedBlackTree when running unit tests does a sanity 
> check of the tree for every operation. If you then use a 
> RedBlackTree in your unit tests, you are doing that again. 
> Maybe it's worth it to you, but it can increase the runtime of 
> your test by orders of magnitude. Last time I checked, 
> performance was high on people's priority lists.

It must be very slow sanity checks :X Sounds weird but I will 
accept it as given. Move the tests out of the RBL definition then.

Also performance has nothing in common with test performance. I 
can't comment about rest because from the very beginning you seem 
to make statements about testing in general which do not match my 
vision at all.