Comment by manv1
3 years ago
"If I could think of all the edge cases myself I would have handled them in my code." - every developer.
It's OK for a developer to write validation tests (ie: tests that ensure the -whatever- is working the way it should). But you really need another team writing its own tests.
That would have saved the crypto guys hundreds of millions of dollars.
That said, this idea is kind of neat. Writing tests is a PITA. But their first example is odd: if you don't know what the expected output is, why are you coding it?
> 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.