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

[Arne Vajhøj]

On 4/9/2022 4:27 AM, chris wrote:
> 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.

With some skill one can pick the critical values with 99 or
99.9 certainty. But it it is not 100% and therefore not proof.

> 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.

I think that is called unit testing with 100% code
coverage in today's terminology.

And it is the right thing to do.

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

Yes.

Arne