Re: else ladders practice

On 19/11/2024 14:29, Janis Papanagnou wrote:

On 19.11.2024 09:19, David Brown wrote:
[...]

>
There are a great variety of projects, [...]

 I don't want the theme to get out of hand, so just one amendment to...
 

Of course testing is important, at many levels.  But the time to test
your code is when you are confident that it is correct - testing is not
an alternative to writing code that is as clearly correct as you are
able to make it.

 Sound like early days practice, where code is written, "defined" at
some point as "correct", and then tests written (sometimes written
by the same folks who implemented the code) to prove that the code
is doing the expected, or the tests have been spared because it was
"clear" that the code is "correct" (sort of).
 Since the 1990's we've had other principles, yes, "on many levels"
(as you started your paragraph). At all levels there's some sort of
specification (or description) that defined the expected outcome
and behavior; tests [of levels higher than unit-tests] are written
if not in parallel then usually by separate groups. The decoupling
is important, the "first implement, then test" serializing certainly
not.
 Of course every responsible programmer tries to create correct code,
supported by own experience and by projects' regulatory means. But
that doesn't guarantee correct code. Neither do test guarantee that.
But tests have been, IME, more effective in supporting correctness
than being "confident that it is correct" (as you say).
 

Both activities are about reducing the risk of incorrect code getting through.  In some cases, one of them is more practical or more effective than the other, while in other situations you want to combine them.
My argument has never been against testing, nor have I claimed that programmers can be trusted to write infallible code!
All I have been arguing against is the idea of blindly putting in validity tests for parameters in functions, as though it were a habit that by itself leads to fewer bugs in code.