Fortran - Re: FORTRAN Unit Test Framework (FRUIT) 2.1 released

Author

Re: FORTRAN Unit Test Framework (FRUIT) 2.1 released

Andrew Chen

2008-01-18, 4:31 am

Regan,

FRUIT is located at Sourceforge, not rubyforge. The URL is:
http://sourceforge.net/projects/fortranxunit
2.1.1 is the latest release.

It is a standard package. You unzip, then untar. I could zip that as
well.

Fruit is platform independent. The source code works for Windows, and
Unix.

Please follow instruction in the README file, or here on the wiki:
http://fortranxunit.wiki.sourceforge.net/
The 3 Minute guide is the first place to start after you unpack the
file.

TDD is Test Driven Development. BDD and rSpec are just variation of
TDD. TDD is a blue pill, never go back after taking that :-) See
here: http://en.wikipedia.org/wiki/Test-driven_development

It is actually surprising that FORTRAN community doesn't have much TDD
practices. I hope FRUIT can help.

If you have anything to share using FRUIT, please feel free to
contribute to the project wiki.

Thanks
~Andrew Chen

Paul van Delst

2008-01-18, 7:15 pm

Beliavsky wrote:
> On Jan 18, 10:55 am, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
>
> You do not mention an obvious reason that I think you aware of -- many
> Fortran programmers are not professional programmers and will invest
> as little as possible in professional practices that don't seem to
> directly push their work forward. If a computational physics professor
> is publishing enough articles in Physical Review by running his
> unindented, no-variables-declared, FORTRAN programs composed on his
> rusty trusty vi editor, he sees no reason to change. Maybe he is
> right :).

You hit the nail on the head there.

But, given that, can we trust the results in said articles as the science code become ever
more complex?

Additionally, how much faster could we run said science code if it was refactored using
"modern" software development practices?

Research funding is hard enough to come by such that I reckon building the cost of
professional programmers into any proposal will cost it out of competition.

cheers,

paulv

Gordon Sande

2008-01-18, 7:15 pm

On 2008-01-18 16:48:23 -0400, Paul van Delst <Paul.vanDelst@noaa.gov> said:

> Beliavsky wrote:
>
> You hit the nail on the head there.
>
> But, given that, can we trust the results in said articles as the
> science code become ever more complex?
>
> Additionally, how much faster could we run said science code if it was
> refactored using "modern" software development practices?
>
> Research funding is hard enough to come by such that I reckon building
> the cost of professional programmers into any proposal will cost it out
> of competition.
>
> cheers,
>
> paulv

A fast cure would be to require that the source for the basis of all
computation based papers be made available through some archive service.

Then anyone who cared could form their own judgement of the quality of
the underlying code. For instance, is it doing what was claimed? And
the editors might get a fix on the quality of the referees!

Pierre Asselin

2008-01-19, 7:12 pm

I'll quote selectively here...

Andrew Chen <hangfei@gmail.com> wrote:
> [ Andrew playing Devil's advocate, I think, ]
> We can not do unit test because our time is too precious, and we
> don't know exactly how and why to unit test.
> [ ... ]
> * Write unit tested code will cost me too much more time - then
> don't do any test, that will save time.

But this is a fallacy, even though it is not an obvious one to
someone who never tried unit testing or test-driven development.
In my experience, there is a good chunk of coding overhead, at
least 1:1 testing code to payload code, but the *total* overhead
is large and negative!

It's not that hard to understand, either. The tradeoff is between
extra coding and extra debugging. Coding is easier than debugging.
In the end the 100% coding overhead is a bargain.

> By the way, our code will run on space shuttles, airplane engines, and
> nuclear plants. [ ... ]

I see hints that this population of scientists is changing its ways.
This url, for example
http://amelia.db.erau.edu/nasacds/2..._2003140390.pdf

--
pa at panix dot com

Bil Kleb

2008-01-19, 7:12 pm

Arjen Markus wrote:
>
> I do not know what the most prominent reasons are - maybe there are no
> specific reasons.

In the beginning, computer time was a scarce resource: you wrote tests
for your routines to make sure they would work as expected before inserting
them into the larger system because an error was really expensive in
both time and dollars, i.e., unit testing was standard practice 30-40
years ago.

Now that computer resources are not so scarce, which has allowed other
methods of development, e.g., the code-n-fix method[1] that McConnell[2]
and others decry.

As others have pointed out and the first two papers on

http://tufte-latex.googlecode.com

discuss, the lack of unit testing is particularly worrisome
on two fronts:

1) It strays from the independent verification foundation
of the Scientific Method, and

2) Applications are only growing more complex as computer power
increases, and if we don't have a solid foundation of components...

Regards,
--
http://twitter.com/bil_kleb

[1] http://en.wikipedia.org/wiki/Code_and_fix
[2] http://cc2e.com

Bil Kleb

2008-01-19, 7:12 pm

Pierre Asselin wrote:
>
> It's not that hard to understand, either. The tradeoff is between
> extra coding and extra debugging. Coding is easier than debugging.
> In the end the 100% coding overhead is a bargain.

I find that developing test-first provides a custom debugger in the
form of automated unit tests -- to the extent that I don't have use
for a traditional debugger, or on the off chance I do need one, they
feel cumbersome and slow.

See also the Prag's /The Art of Enbugging/ article: http://tinyurl.com/2axbp3

> I see hints that this population of scientists is changing its ways.
> This url, for example
> http://amelia.db.erau.edu/nasacds/2..._2003140390.pdf

We've been trying. Actually, that paper has resulted in 8
invited lectures across the U.S., so there does seem to be
interest...

Regards,
--
Bil Kleb
http://fun3d.larc.nasa.gov

Paul van Delst

2008-01-22, 8:22 am

Gordon Sande wrote:
> On 2008-01-18 16:48:23 -0400, Paul van Delst <Paul.vanDelst@noaa.gov> said:
>
>
> A fast cure would be to require that the source for the basis of all
> computation based papers be made available through some archive service.

Crkiey, I've been trying for 5+ years to get source code made available to
*developers*.... and they're in the same building (one is in the next cube fer pete's
sake). We only just recently (last Oct) got a *read-only* repository up and running.

Now the task of getting them to learn about version control is rearing...

cheers,

paulv

> Then anyone who cared could form their own judgement of the quality of
> the underlying code. For instance, is it doing what was claimed? And
> the editors might get a fix on the quality of the referees!
>
>
>
>

Paul van Delst

2008-01-22, 8:22 am

Andrew Chen wrote:
> OK. We are physicists and engineers. We don't want to be
> professional programmers, and we can not work or can not hire
> professional developers because lack of money or developers lack of
> IQ. We can not do unit test because our time is too precious, and we
> don't know exactly how and why to unit test. Even though all other
> professional developers do that kind of stuff.
>
> By the way, our code will run on space shuttles, airplane engines, and
> nuclear plants.
>
>
>
> Those are all "claims" I've heard of:

All your claims I've heard too. And the counter arguments. I agree. However, without a
bunch of extra $$==people (i.e. management support), trying to individually surmount these
problems -- while still trying to get one's "regular" work done -- on large complex codes
is a sisyphean task.

The push has always been to increase productivity for the same cost. One end result of
this is that free time to play and experiment with "new" techniques is extremely limited.

Bil Kleb recently posted a link to an abstract that included a plot of the Satir five
stage change model diagram. I reckon nowadays there is little or no margin to handle the
"resistance" and "chaos" stages and still deliver product.

All my own opinions of course. Any resemblance to actual circumstances is purely
coincidental. :o) I don't speak for NOAA (or anyone else) and they don't speak for me.

cheers,

paulv

> * My domain is too complex and hard to test - every domain is
> complex
> * Write unit tested code will cost me too much more time - then
> don't do any test, that will save time.
> * My underlying physics model is in nature, the solution is based on
> iterative calculation - isolate, and write a simulator for that.
> * I don't know how to write unit test, and I don't care to learn
> - ???!!! It boils down to if anyone cares about the code run
> correctly.
> * There is not enough tools for FORTRAN - well, there are about 4
> unit testing framework out there. If the work is important enough,
> tools will come.
> * I only did waterfall before in the past 30 years, and some of them
> were successful , what is this TDD/unittest fuss about? - TDD/
> unittest has been commonly accepted by the software development
> community, it makes your development successful easier.
> * I have legacy system that did not have enough tests - well, it is
> hard. Make sure all new codes have tests. Also read the book
> "Working with Legacy Codes"
> * FORTRAN subroutines tends to be larger, and hard to test - TDD and
> refactoring are good tools to solve this problem. Large subroutine is
> not a language problem, it is a design problem.
>
>
> ~Andrew Chen

Sponsored Links