[ANN] FORTRAN Unit Test Framework (FRUIT) 2.1 released
Andrew Chen
FRUIT is a unit testing utility written for FORTRAN. The project
started in 2004 when I did development in FORTRAN. Westinghouse
donated this project to open source community.
Features of FRUIT include:
1. Pure FORTRAN, so all modules and subroutines can be tested. Core
modules are just 2 FORTRAN files.
2. Follows XUnit guidelines, it handles setup/teardown, test_xxx .
3. Enables you to do Test Driven Development, and Behavior Driven
Development in FORTRAN.
FRUIT 2.1 is just released.
There are significant improvements in this release.
1. The user only has to maintain module_test.f90. It is one module.
The drivers are generated automatically by ruby script.
2. Created one complete sample of how to use the code.
3. Enhanced the report, and usability.
4. Switched from make to rake. Now I can handle a lot of
automatically generated code stuff. This project has a complete build
system.
5. Added features such as rSpec. So that you can really do TDD, and
BDD, to have one executable requirement. This is pretty powerful, if
you put that into your process. Then your requirement document, test
plan, test report can be automatically generated.
Please see the sourceforge project:
http://sourceforge.net/projects/fortranxunit
After you download, the sample directory shows major features. I'm
writing some more samples on the project wiki (http://
fortranxunit.wiki.sourceforge.net/) . I'm looking for contributors to
this project.
Enjoy your fruit!
Regards
--
Andrew Chen
BEACON Core Monitoring Product, Nuclear Fuel
Westinghouse Electric Company
412-374-2316
Bil Kleb
> Hi,
Hi.
> FRUIT 2.1 is just released.
Most welcome news, I thought we'd lost you!
> 1. The user only has to maintain module_test.f90. It is one module.
> The drivers are generated automatically by ruby script.
Uh oh, you've gone to the dark side! :)
> 4. Switched from make to rake. Now I can handle a lot of
> automatically generated code stuff. This project has a complete build
> system.
Excellent; I've been thinking along those lines.
> 5. Added features such as rSpec. So that you can really do TDD, and
> BDD, to have one executable requirement. This is pretty powerful, if
> you put that into your process. Then your requirement document, test
> plan, test report can be automatically generated.
Wow. Neat.
Regards,
--
Bil Kleb
http://nasarb.rubyforge.org/funit
Andrew Chen
" > Uh oh, you've gone to the dark side! :) "
Haha, Ruby was the fun part!
It turned out that FORTRAN is a very structured language to generate,
and Ruby is really a powerful tool!
The main goals of FRUIT are:
1) have FORTRAN code unit tested.
2) make TDD possible in FORTRAN
Ruby is only used to generate FORTRAN driver code. All core parts of
FRUIT are pure FORTRAN (95). User can use FRUIT without the Ruby
part. See my example: "Add Fruit to Your Diet in 3 Minutes - TDD in
FORTRAN" (http://fortranxunit.wiki.sourceforge.net/FruitExample). It
is pure FORTRAN.
>
> > 4. Switched from make to rake. Now I can handle a lot of
> > automatically generated code stuff. This project has a complete build
> > system.
>
> Excellent; I've been thinking along those lines.
It took me a while to re-make the whole build system in rake.
Discussion of rake vs. make is a little off the FORTRAN topic here,
however, each FORTRAN developer has to maintain some kind of build
system.
Rake has many advantages over make, to compile traditional language:
1. It handles wild-card better. By adding one a.f90, I don't have to
specify that in 4 different places in Makefile. I don't need to do
anything. Well, make can do this, kind of.
2. It handles generated code well. I have a situation that new
FORTRAN modules (drivers) source codes are generated based on test
codes. The build system has to build the original test modules first,
then build the drivers. Rake could handle it.
3. The rakefile is simple and elegant. I don't have to maintain 500
lines Makefile any more.
4. Rake comes with clean and clobber target.
5. Rake can communicate with ruby, and other gems natively. So it is
a lot more powerful than Makefile.
I think the build system comes with FRUIT can be scaled up if you need
one rake example for FORTRAN/C/C++, or mixed languages.
Cheers!
~Andrew Chen
Reagan Revision
"Bil Kleb" <Bil....@NASA.gov> wrote in message
news:fmo71s$c6c$1...@aioe.org...
horizons and see about this FRUIT product. The example you give with
"Preparing FRUIT in three minutes" emboldened me to think that I would
download the software. Ultimately I found myself with something that looked
like the download of fruit_2.1_tar.gz . "tar.gz" is the kiss of death for
me. Am I correct to think that this software is of little utility to a
windows user sans cygwin?
>
> Wow. Neat.
>
> Regards,
> --
> Bil Kleb
> http://nasarb.rubyforge.org/funit
I'm very interested in how I would get a language that I have a background
in, fortran, to operate with ruby, where everyone's a newcomer. I've chased
the link at your sig before and wonder aloud what the funit is in the
rubyforge project at nasa?
--
Reagan Revision
"We are being told that a competent, trustworthy president is someone
who brandishes his religion like a neon sign, loads a gun and goes out
hunting for beautiful winged creatures, and tries to imitate a past
president who, by the way, never shot a bird or felt the need to imitate
anybody."
~~ Patti Davis Is Not Flattered by GOP Candidates' Pale Imitations of
Her Father
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Andrew Chen
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
Bil Kleb
>> Bil Kleb
>> http://nasarb.rubyforge.org/funit
>
> I'm very interested in how I would get a language that I have a background
> in, fortran, to operate with ruby, where everyone's a newcomer.
Ruby is only used to generate Fortran (like FRUIT now does),
so you don't have to learn Ruby to use fUnit.
Ruby comes installed on *nix systems and can be freely downloaded
for systems that do not have it -- see http://ruby-lang.org
> I've chased the link at your sig before and wonder aloud what the funit
> is in the rubyforge project at nasa?
Does the link not take you to the contents of a README.txt
file that has the following?
DESCRIPTION:
FUnit is a unit testing framework for Fortran modules.
Unit tests are written as Fortran fragments that use a small set
of testing-specific keywords and functions. FUnit transforms these
fragments into valid Fortran code, compiles, links, and runs them
against the module under test.
I am confused by your confusion; please help.
Regards,
--
Bil Kleb
http://fun3d.larc.nasa.gov
Arjen Markus
>
>
> 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.
>
I am curious about that myself - not so much that the trendy acronym
is
relatively unknown within our community, but that unit testing and
other forms
of (regression) testing do not seem to evident, essential tools of the
trade.
I can think of a large number of reasons, based on my own experiences:
- It is tedious to keep small test programs around together with the
test input and reference output.
- Many Fortran programs are vast and would require loads of such test
programs.
- The language itself can hinder unit tests - as you can not hide the
test programs inside the source files, as you can with C, using
preprocessor
macros for instance.
- The Fortran IDEs do not support unit testing, as you see with Java
IDEs.
- Numerical results may vary independently of changes in the source
code due
to different compilers, compiler options and so on.
- Fortran routines tend to be larger in general (with more input and
output parameters)
than the (very) small routines you typically see with object-
oriented languages.
(The fact that you need many calls to these routines to get
something done,
could make it more attractive to spend time writing tests for each
of them.)
I do not know what the most prominent reasons are - maybe there are no
specific
reasons.
Anyhow, managing small test programs (seemingly) separately from the
main body
of the program was what made me write my unit testing framework (cf.
http://flibs.sf.net).
Regards,
Arjen
Beliavsky
> On 18 jan, 05:51, Andrew Chen <hang...@gmail.com> wrote:
>
>
>
> > 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.
>
> I am curious about that myself - not so much that the trendy acronym
> is
> relatively unknown within our community, but that unit testing and
> other forms
> of (regression) testing do not seem to evident, essential tools of the
> trade.
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 :).
Paul van Delst
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
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!
Andrew Chen
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:
* 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
Pierre Asselin
Andrew Chen <han...@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/200401Disc3/research/20040006359_2003140390.pdf
--
pa at panix dot com
Bil Kleb
>
> 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
>
> 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/200401Disc3/research/20040006359_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
Wade Ward
> 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.
Now that this thread has gone on a bit, I definitely want to put in
some time on this. I am, however, at square one. I googled for
"unzip untar" and got information that would inform a Linux user. I
then googled for "unzip untar windows" and got information that would
only inform a Linux user.
With unzipping, I either have an unzip ready on the right click, or I
have to download winzip for the 47th time. How does one untar, given
that by this, you don't mean with acetone?
The other time Google is handy is when your regular news server is
down.
--
Fly Away
> With unzipping, I either have an unzip ready on the right click, or I
> have to download winzip for the 47th time. How does one untar, given
> that by this, you don't mean with acetone?
Install 7zip - http://www.7-zip.org/. It unpacks all common types of
archives and can pack in most of the formats, except some proprietary
ones like rar. It's free, open source, cross platform, integrates
smoothly in Windows so you can do your much desired right click
thingy. It sure does a lot more than this.
Cheers,
Victor.
Paul van Delst
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
Paul van Delst
> 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
nobat
> Enjoy your fruit!
>
> Regards
> --
> Andrew Chen
> BEACON Core Monitoring Product, Nuclear Fuel
> Westinghouse Electric Company
> 412-374-2316
Hi;
Thank you for providing us with FRUIT.
I am pretty new to Ruby (so sorry for asking seem-to-be-an-obvious-
question)
Following the installation instructions (fruit 2.1.1), from (http://
fortranxunit.wiki.sourceforge.net/Installation+Guide)
I get the following message at step 4:
Version: ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32] (W
Step 4)
rake install
gem install pkg/fruit_processor-2.1.1.gem
rake aborted!
undefined method `exitstatus' for nil:NilClass
C:/Temp/Fortran/fruit/fruit_processor_gem/rakefile:29
(See full trace by running task with --trace)
With --trace option:
gem install pkg/fruit_processor-2.1.1.gem
rake aborted!
undefined method `exitstatus' for nil:NilClass
D:/Logiciels/ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:899:in
`sh'
D:/Logiciels/ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:906:in
`call'
D:/Logiciels/ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:906:in
`sh'
D:/Logiciels/ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:985:in
`sh'
C:/Temp/Fortran/fruit/fruit_processor_gem/rakefile:29
D:/Logiciels/ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:546:in
`call'
D:/Logiciels/ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:546:in
`execute'
D:/Logiciels/ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:541:in
`each'
D:/Logiciels/ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:541:in
`execute'
D:/Logiciels/ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:508:in
`invoke_with_call_chain'
D:/Logiciels/ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:501:in
`synchronize'
D:/Logiciels/ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:501:in
`invoke_with_call_chain'
D:/Logiciels/ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:494:in
`invoke'
D:/Logiciels/ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:
1931:in `invoke_task'
D:/Logiciels/ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:
1909:in `top_level'
D:/Logiciels/ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:
1909:in `each'
D:/Logiciels/ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:
1909:in `top_level'
D:/Logiciels/ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:
1948:in `standard_exception_handling'
D:/Logiciels/ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:
1903:in `top_level'
D:/Logiciels/ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:
1881:in `run'
D:/Logiciels/ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:
1948:in `standard_exception_handling'
D:/Logiciels/ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:
1878:in `run'
D:/Logiciels/ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/bin/rake:31
D:/Logiciels/ruby/bin/rake:16:in `load'
D:/Logiciels/ruby/bin/rake:16
Nobat
Andrew Chen
FRUIT was not tested on Windows. It was developed on Linux, and
should run on other platform.
I don't have a FORTRAN compiler on Windows. There are areas that are
Unit specific, where the directory lookup with "/" or "\", and where
the root directory is.
However, it seems like your problem is that you can not install the
gem:
gem install pkg/fruit_processor-2.1.1.gem
Do you have problem installing other gems?
Can you try this?
gem install fruit_processor-2.1.1.gem
The fruit processor provides convenient tools for code generation, and
the build system.
Thanks
~Andrew Chen
>
> I am pretty new to Ruby (so sorry for asking seem-to-be-an-obvious-
> question)
>
> Following the installation instructions (fruit2.1.1), from (http://
Gerry Ford
"nobat" <sk.n...@gmail.com> wrote in message
news:f9953883-f4fa-4884...@i7g2000prf.googlegroups.com...
>> Enjoy your fruit!
>>
>> Regards
>> --
>> Andrew Chen
>> BEACON Core Monitoring Product, Nuclear Fuel
>> Westinghouse Electric Company
>> 412-374-2316
>
> Hi;
>
> Thank you for providing us with FRUIT.
>
> I am pretty new to Ruby (so sorry for asking seem-to-be-an-obvious-
> question)
Fortran's modus operandus (sp?) is not attacking the opposition, so don't be
shy.
--
/rake-0.8.1/lib/rake.rb:
> 1878:in `run'
> D:/Logiciels/ruby/lib/ruby/gems/1.8/gems/rake-0.8.1/bin/rake:31
> D:/Logiciels/ruby/bin/rake:16:in `load'
> D:/Logiciels/ruby/bin/rake:16
>
> Nobat
--
The most common of all follies is to believe passionately in the palpably
not true. It is the chief occupation of mankind.
-- H L Mencken, A Mencken Chrestomathy (1949)
Arjen Markus
>
> Fortran's modus operandus (sp?) is not attacking the opposition, so don't be
> shy.
The correct term is "modus operandi" (I will spare you the grammatical
explanation,
mostly because I am a bit rusty on that myself ;))
Regards,
Arjen
Gary Scott
> Sorry for late reply
>
> FRUIT was not tested on Windows. It was developed on Linux, and
> should run on other platform.
>
> I don't have a FORTRAN compiler on Windows.
They are free!
<snip>
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
paul.rich...@gmail.com
You will see from a recent thread that Gerry Ford was enquiring about
building fruit using gfortran.
Well, gfortran does just fine as long as two standard defying lines
are changed:
s/function get_last_message_/function get_last_message_ ()/
s/function is_last_passed_/function is_last_passed_ ()/
Cheers
Paul