Re: Testing relational databases

Bob Badour wrote:

> I read it. It made tremendous sense. Others read it and made sense of it
> too. The only people I have encountered who reached the same conclusion as
> you were demonstrably stupid. Sadly, I have to conclude the same of you.

And everyone else both these newsgroups consider Fabian a crackpot except you.

Oh, if only we were as smart as you, to figure out what Fabian's point is inside all the ranting!

> Doesn't it strike you as stupid to expend energy on tests that one could
> more productively expend on proofs?

Those aren't real math proofs. They are softer, within the non-rigorous constraints of hardware and software. Hence, they are a lot like unit tests. Just harder to write.

The most advanced proofs guys, on the Ada SPARKS project, have admitted they frequently make small edits to their code, then pass all their tests - oops I mean proofs.

Put another way, their design emerges within constraints, programmed first. That sounds familiar...

>> The goal is code designed for testing, so that tests and clean code,
>> together, can inhibit bugs. So if you design BY testing, then you are in
>> the best position to possibly discover the remaining few.
>
> That in no way causes the probability of correctness to approach unity
> with the certainty required to overcome P^N when N is large. For example,
> a probability of 90% correct for each of 100 units gives a probability of
> only 0.0027% correct for the resulting system. A probability of 99%
> correct for each of 100 units gives a probability of only 37% correct for
> the resulting system.

Nobody needs to use tests to proof correctness. You are not responding to the claim that proof-first, and test-first, help the code resist bugs. There's a difference.

> As the system grows larger, the certainty required approaches even closer
> to unity. For 1000 modules, even if one achieves a 99.9% certainty of
> correctness for each unit, the system has only a 37% chance of
> correctness.

I thought the same could be said of proofs.

So it's a good thing neither group attempts to exhaustively prove correctness.

> Following Amblers advice means expending considerable effort on tests to
> achieve an almost certainly buggy system.

Uh, other people promote TDD besides Ambler. And teams who use it overwhelmingly report an order of magnitude fewer defects. So once again you link a non-sequitur to an imagined conclusion that is not observed in real projects.

> Plonk.

Oh, pleeease please please!!

;-)

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!