Re: Testing relational databases
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...
>> 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