Question(s)

[o1bigtenor]

On Tue, Oct 24, 2023 at 5:28 PM Rob Cliffe <rob.cliffe at btinternet.com> wrote:
>
> There is no general way to prove that a program is "correct".  Or even
> whether it will terminate or loop endlessly.
> These are of course theoretical statements of computer science.  But
> they can be rigorously proven.  (Sorry if I'm just saying this to show
> what a smart-ass I am. 🙂)
> In practice, of course, there is often a great deal that can be done to
> "verify" (a word whose meaning I intentionally leave vague) a program's
> correctness.
> In your case, it sounds as if you should
>
>      Write programs or functions to simulate each piece of hardware and
> generate random, but reasonably realistic, data.  (Python and most other
> programming languages provide means of generating random or
> pseudo-random data.)
>      In your main program:
>          Replace the bits of code that accept data from the hardware by
> bits of code that accept data from these simulation programs/functions.
>          Write the decisions it makes to a log file (or files).
>      Run the program as long as you can or until your patience is
> exhausted, and check from the log file(s) that it is behaving as you
> would expect.
>
> This is not guaranteed to catch all possible errors.  (Nothing is.) E.g.
>      The original code to accept data from the hardware (code that you
> remove in your test version of the program) might be wrong. Duh!
>      There might be specific sets of input data that happen not to arise
> in your testing, but that your program logic does not cope with.
> Nonetheless, this sort of testing (if done diligently) can give you a
> high degree of confidence in your program.
> And it is a good idea to do it.
> When you come to run your program "for real", and you have to
> troubleshoot it (as in real life you probably will🙁), you will have
> eliminated simple bugs in your program, and can concentrate on the more
> likely sources of problems (e.g. misbehaving hardware).
>
Interesting - - - hopefully taken in the same vein as your second statement - -
I sorta sounds like programmers keep running around in the forest looking
for trees. (Grin!)

So how does one test software then?

Tia