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.
