[Info-vax] Rust as a HS language, was: Re: Quiet?

[chris]

On 04/08/22 01:36, Arne Vajhøj wrote:
> On 4/7/2022 2:58 PM, Dave Froble wrote:
>> On 4/7/2022 1:39 PM, Simon Clubley wrote:
>>> BTW, testing can only prove the presence of bugs and not the absence
>>> of them. Someone else can still come along and do testing in a different
>>> way that finds undiscovered issues. Look at the stuff about EVL that
>>> I posted recently as an example.
>>
>> Not if all possible outcomes are expected and handled.
>>
>> A good design will include handling all possible outcomes.  Anything
>> else is just when, not if, something unexpected occurs.
>
> True.
>
> But not particular relevant.
>
> Too many cases to test.
>
> If your program take 1 KB of input then there are
> 2**8192 possible inputs. That is a pretty big number.
>
> But it is what it takes to prove that this
> program is correct by test.

Good design range checks all input against the limits
that the code can handle. Anything else is sloppy, but is
seen everywhere these days. No excuse for design errors
like that, as it's so easy to avoid.

>
> Of course you can probably pick a couple of handful
> careful designed test cases and if they work, then you
> are somewhat optimistic that the program will work in
> general. But that is different from proving.
>
> Arne
>

For work here, tend to write a test harness for every
module as part of the build process, with data designed
to stress test the code well outside expected limits,
as well as with valid data.

Of course, that doesn't prove that the overall system
design is correct and that is often where the real
testing problems arise...

Chris

>