Possible solution for export : `unittest export`?

[deadalnix via Digitalmars-d]

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.

Change the text on a button, the test is broken. Wait, the 
translation team changed the text on the button in tagalog ? Why 
don't these linguist learn of to fix a unittest !

Well, we'd better have an id on the button rather than relying on 
the text. Now the button is not displaying properly because of an 
text encoding issue, but nobody knows about it because it has the 
right id. Damn...

And that is just for one button...

There are solutions, like webdriver tests (or native equivalents) 
and so on, but they only cover a small portion of the app and 
tend to be fragile, so using them more is not always a good idea. 
One tend to only use them for critical flow, like the purchase 
tunnel on a e commerce, or the registration flow on a social app.

> 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. That 
comes very handy with continuous integration. And bisect.

> 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.