Re: Testing relational databases

From: S Perryman <a_at_a.net>
Date: Mon, 10 Jul 2006 15:56:38 +0100
Message-ID: <e8tphm$ts0$1_at_nntp.aioe.org>


"Phlip" <phlipcpp_at_yahoo.com> wrote in message news:Njjsg.1675$2v.762_at_newssvr25.news.prodigy.net...

> Bob Badour wrote:

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

Bob, the productivity gains are known.

For example, Praxis CS (safety-critical s/w developers) showed on one project
quite significant ROI on defect prevention and detection by using proof-based

techniques, compared to the usual test approaches (unit testing etc) .

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

Strange then is it not, that Praxis CS tell the world that they spend such a large
proportion of time (compared to industry) precisely specifying/proving systems
*before even a line of code is written* (interested readers : IEEE Spectrum -
September 2005) ...

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

TDD : write some code to make a test pass. That is not "designed for testing" .

Regards,
Steven Perryman Received on Mon Jul 10 2006 - 16:56:38 CEST

Original text of this message