Maybe, with your experience, you are right. But I am scared after seeing all the solid theories fail time and time again.

Of course, I have seen "solid theories" fall. However, I have, by an order of magnitude or more, seen "tested" products fail.

If I apply an untested "solid theory" I will spend more time verifying the theory, than verifying the application applying it.

The (sad?) fact is that you can not "test" all possible scenarii a code may be exposed to, and thus "testing code" is, by definition, faulty, I recall a screwup of mine where everything worked till you, by mistake, double pressed '7' on the keypad. If, instead, you analyze the theory as such, you will have a much clearer picture.

a simple example: you have to code (x squared minus y)
If you decide to go ahead and code it, will you get ALL the folloeing cases considered?
x positive, y positive
x negative, y positive
x negative, y negative
x positive, y negative
x zero, y positive
x negative, y zero
x positive, y zero
x zero, y zero
x zero y negative
and in all cases the result may be positive, negative or zero.
what abot x being so large that the result overflow the result store?

This example may not be extremely valid in C, but visualize it in assembler

So, if you do this excersize on paper BEFORE you code, you will be much more likely to code correctly than if you just go ahead and code because "the testing will catch if I am wrong".

The above simple example (3 numeric variables, no if, for, while ...) even show how complex a complete test suite will be.

Do you REALLY believe. that if complete "testing" is virtually impossible of such a simple function, that "testing" proves diddlysquat?

Erik