Quit running foreign unittests >_<

[Ivan Kazmenko via Digitalmars-d]

On Tuesday, 28 April 2015 at 16:40:05 UTC, Dicebot wrote:
> On Monday, 27 April 2015 at 11:30:04 UTC, Steven Schveighoffer 
> wrote:
>> On 4/27/15 6:20 AM, Dicebot wrote:
>>> On Monday, 27 April 2015 at 10:15:20 UTC, Kagamin wrote:
>>>> On Monday, 27 April 2015 at 09:22:48 UTC, Dicebot wrote:
>>>>> Compiling tests of dependencies pretty much never causes 
>>>>> any notable
>>>>> slowdown.
>>>>
>>>> This thread doesn't support that view, see the first post.
>>>
>>> Which part exactly? I only see comparisons for compiling AND 
>>> running
>>> tests for dependencies. And it is usually running which 
>>> causes the
>>> slowdown.
>>
>> The problem is as follows:
>>
>> 1. Unit tests for some library are written for that library. 
>> They are written to run tests during unit tests of that 
>> library only (possibly with certain requirements of 
>> environment, including build lines, or expectations of system 
>> resource availability).
>> 2. People who import that library's modules are not trying to 
>> test the library, they are trying to test their code.
>
> Those are two points I fundamentally disagree with. It doesn't 
> matter where the code comes from - in the end only thing that 
> matters is correctness of your application as a whole. And 
> considering tests are not necessarily pure the results may very 
> well differ between running those tests spearately and as part 
> of application test suite a whole. 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.
>
> And if tests are written in a weird way that they can only be 
> ran within that library test step, those are not really 
> unittests.
>
> Usage of version(MyLibTests) in Nick SDL library annoyed me so 
> much that I forked it to never deal with those pesky versions 
> again. Don't want to do that with Phobos too.

Then how do you propose to approach the containers problem?

On one hand, a unittest on containers themselves involves testing 
the container for integrity after each operation.

On the other hand, a unittest on another module may involve heavy 
use of containers (say, N operations with a container), and if 
integrity checks are enabled at this time, it totals to N^2 
trivial operations which may not be feasible.

Ivan Kazmenko.