In article <dt5493$b4f$1@vilya.larc.nasa.gov>,
Bil Kleb <Bil.Kleb@NASA.gov> wrote:
>Paul Van Delst wrote:
.
.
.
>> The one thing I'm still having trouble with is: if you
>> want to component test various modules of a software package (in my
>> case, all in Fortran95), where does all the Ruby (or Python) stuff come
>> into it? I mean, what do you actually use Ruby (or Python) for?
>
>Got some links (a bit old) for that one too. ;)
>
> http://www.devsource.com/article2/0,1759,1778699,00.asp
> http://www-128.ibm.com/developerworks/linux/library/l-oslab/
> http://www.rubygarden.org/ruby?WhatDoesNasaUseRubyFor
> http://www.rubyquiz.com/quiz46.html
> (see also the front page of our FUN3D website)
.
.
.
I think there's more to say (and thanks, by the way, for the
advertisement--the l-oslab reference above). We still need
to write an explanation aimed at Fortran programmers of
exactly why test composition is more productive in a high-
level language.
One approach is to ask why people don't write unit tests in
Fortran (in fact, some do; as it happens, the very first
program I wrote for an electronic computer was in FORTRAN,
and unit-tested trigonometric results). Somehow, it feels
ardurous; in a dynamic language, though, a test collection
can be as simple and easily maintained as
do_test attach-1.4 {
execsql {
SELECT * FROM t2;
}
} {1 x 2 y}
do_test attach-1.5 {
execsql {
DETACH DATABASE two;
SELECT * FROM t1;
}
} {1 2 3 4}
do_test attach-1.6 {
catchsql {
SELECT * FROM t2;
}
} {1 {no such table: t2}}
This is a tiny segment of the massive automated Tcl-coded
testing the remarkable sqlite distribution builds in.
Eventually, I'd like to get permission to write about some
of the tests I've written for engineering projects. There's
an important question here, and I think we can answer it
better.
Received on Sun Apr 30 02:17:55 2006