Comment by IIsi50MHz

> But their first example is odd: if you don't know what the expected output is, why are you coding it?

My first thought: to discover outputs to then expect. Whether you have a vague idea or no idea of the outputs, it can be a useful starting point.

You might use it on something that's completely novel, or is poorly documented, or for 'black box' testing. "What happens when I tell the Foo to Baz with a bar, instead of a crunchly? Does it change if I already have a baz?"

Not really related, but… "Does the set of rows returned include rows that should not be there when the DB has per-record security enabled, the COM host is holding a reference to the initialised SQL driver, and I run a new query with lower access credentials without disposing of the reference?"[1]

[1] Vague memories of a Sage 300 CRE security bug.