Re: Transactions: good or bad?

> Absolutely not. It may still be riddled with bugs. I demonstrated a
> simple example of this in an earlier posting in this thread...

I saw that and it was an excellent example.

> This only works if your test coverage includes every possible set of
> inputs.

Are you sure about that?

In your example, you used

a || b

If I have lead you to believe that my analysis idea was strictly data based I am in error. In the back of my head I've been thinking expert systems type of an approach all the way. That is, use the logical assertions of the program to generate enough test data to test the other logical assertions, and let an operator / business owner check it against requirements. This is pie in the sky technology but this is a pie in the sky forum - "theory".

To demonstrate a bad implementation of a function that is supposed to return true if and only if both a and b were true. It shows that you cannot just have a single set of inputs to this function. In our case, in fact, there are basically four inputs needed to test it, the permutations of a and b being true or false. But that is a long way from -every possible input-.

So, instead of looking at just if - then elses, we would also need to have some understanding of how the language primitives work, in order to prove our application. From there, it seems reasonable to build an inference engine with the language primitives at its lowest level, and then use the program itself to add rules to that inference tree / knowledge base, whatever, and then, finally, have requirements that test all of the assertions made by the program to see if they are consistent. To do this in a meaningful way, and to be fairly strong about it, you need to have questions be asked so that every conditional / expression are hit at least once.

In your above example, the testing engine would most certainly have to know about the behavior of a || b and understand that there needs to be four test cases, if the function is used only for conditional logic, and, some x number of more test cases depending on how it is used in other logic. An operator of the testing system could supply / override stuff.

If people can make proofs, why can't computers? While creating a proof may not be an algorithm, checking one most certainly is, is it not? Having a complex digital system be checked by a manual process on paper seems absurd and is there not a way formally verify systems? I know they did a lot of work on trying to get computers to write proofs for new things, but, for businesses, the relevant question is, will this code satisfy these requirements. Certainly requirements can be modelled as logical assertions.

> That would be equivalent to a proof. Note that an actual proof of the
> program would be substantially easier.
>
Received on Wed Jun 11 2003 - 19:01:48 CEST