Re: How does one avoid tautologies in testing?

Isn't the act of testing per definition a redundancy and therefore tautologies not avoidable?

I think even the name is wrong, shouldn't it be called "assuring" instead of "testing".

For example: If I try if a knife cuts a piece of paper before I buy it in a shop, I'm testing this unknown knife. Who knows if it's sharp otherwise?

But if I try my knife just after I sharpened it, I'm assuring that it's sharp, even if I already should know it's redundant to do so!

Don't be to critical about your test-suite! Only when you encounter a new bug which wasn't found by you're tests, you can be sure that you're tests haven't been sufficient. And only by a adding a new test covering this bug, you can approximate the ideal test suite. It's a dynamic process.

Beside philosophical thoughts, can't you just automatically record real live "BUCOs" and reuse them afterwards instead of generating them artificially?

Cheers Rolf

Comment on Re: How does one avoid tautologies in testing?

Replies are listed 'Best First'.
Re^2: How does one avoid tautologies in testing? by moritz (Cardinal) on Jul 15, 2009 at 22:30 UTC
Isn't the act of testing per definition a redundancy and therefore tautologies not avoidable? No, testing in the sense that it's used in programming is checking actual results against expected results. A tautology is a logic expression or formula that's always true - not only when your program is working, but also when it's broken. For example the addition operator `+` is rather primitive, and you're hard-pressed to test it in terms of even more primitive operations. If you accidentally test `+` in terms of `-`, and for the CPU that's the same operation, your test will always pass, even if the arithmetic unit in your CPU is broken - as long as it's still deterministic. However if you test it in terms of examples, a broken `+` can be detected - no tautology here. For example: If I try if a knife cuts a piece of paper before I buy it in a shop, I'm testing this unknown knife. Who knows if it's sharp otherwise? But if I try my knife just after I sharpened it, I'm assuring that it's sharp, even if I already should know it's redundant to do so! Not all tests are regression tests.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: How does one avoid tautologies in testing?
by moritz (Cardinal) on Jul 15, 2009 at 22:30 UTC

Isn't the act of testing per definition a redundancy and therefore tautologies not avoidable?

No, testing in the sense that it's used in programming is checking actual results against expected results.

A tautology is a logic expression or formula that's always true - not only when your program is working, but also when it's broken.

For example the addition operator + is rather primitive, and you're hard-pressed to test it in terms of even more primitive operations. If you accidentally test + in terms of -, and for the CPU that's the same operation, your test will always pass, even if the arithmetic unit in your CPU is broken - as long as it's still deterministic.

However if you test it in terms of examples, a broken + can be detected - no tautology here.

For example: If I try if a knife cuts a piece of paper before I buy it in a shop, I'm testing this unknown knife. Who knows if it's sharp otherwise?

But if I try my knife just after I sharpened it, I'm assuring that it's sharp, even if I already should know it's redundant to do so!

Not all tests are regression tests.

[reply]
[d/l]
[select]