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.
