[u-u] On testing Re: jobs @ rakuten/kobo

[arocker at Vex.Net]

>> as the tester may not know what was the program is supposed to do.

That would be a good indicator that the purpose had not been communicated
clearly.

>> operating environment itself becomes unstable and unpredictable under
these conditions, and the test results may not mean much.

I must admit that I don't bother to check the return code from a print,
because I reckon that if "print" isn't working, the roof's falling in
anyway.

> A past boss was adamant that our code was untestable because the human
> in the loop was too dynamic a thing to replace.

Yes and no. No matter how thoroughly a knowledgeable designer crafts test
cases, random humans can usually create unforeseen conditions. That's why
having a "village idiot" in the testing cycle is so helpful.

> But I think that running a few captured inputs to the same outputs

Useful not least because it confirms that the input spec. approaches
reality. At the other extreme, a company for which I worked considered the
final check of any program accepting input from the outside world was to
feed it its own binary, backwards. (Easy to do with punched cards.) It was
expected to run to end without barfing, and produce reasonable results
(error messages, batch totals, &c.)

P.S. Whatever happened to parallel running before going live?

The point about separating UI, validation, processing, &c. is a good one.
Simpler code, simpler tests, more flexible and more reusable.
.
> I've heard good things about Documentation-Driven Development,

Essentially what I was suggesting, except you write the tests from the
documentation.