Possible solution for export : `unittest export`?

[Dominikus Dittes Scherkl via Digitalmars-d]

On Tuesday, 1 September 2015 at 19:42:51 UTC, deadalnix wrote:
> On Tuesday, 1 September 2015 at 18:25:06 UTC, H. S. Teoh wrote:
>> That would explain why GUI apps tend to be buggy and 
>> unreliable, and RNGs tend to have unintended biases.
>>
>> No, actually, GUIs should be written to be testable (e.g., 
>> input should be abstracted via dependency injection so that 
>> GUI interactions are scriptable, at least inside a unittest, 
>> with expected final states).
>>
>
> You can test the framework that way. You can't test the usage 
> of the framework that way, especially if you want rapid 
> iteration.
But at least you can unittest all paths in a template so that 
every called function occures in at least one test - this is all 
what is needed for the proposed change of "export", or am I wrong 
here?

> Change the text on a button, the test is broken.
A test for some concrete button?
I would say, thats a little too deep. And of course nothing 
within a library or exported, I would suspect.

>> RNGs can be unittested for uniform distribution within certain 
>> bounds. Unittest does not necessarily mean checking for 
>> equality (even though that's the most common usage).
>>
> Sure, and if they work properly, they should fail randomly.
No. Tests for distribution may only sometimes need longer until 
the statistics come into the valid range. Nevertheless that are 
useful and valuable tests.

>> You might be right about concurrent code, though. Unless you 
>> make it possible to substitute CPU scheduler via dependency 
>> injection, it's probably not unittestable.
>
> It is not unitestable.
But we have concepts like "thread local per default" and message 
passing that should make avoiding race conditions easier. And 
concurrent code doesn't prevent us from testing all paths of 
templates.