fUnit

= FUnit: a Fortran Unit Testing Framework

FUnit is a {unit testing}[http://en.wikipedia.org/wiki/Unit_testing] framework for Fortran modules.

Unit tests are written in Fortran fragments that use a small set of testing-specific keywords and functions. FUnit transforms these fragments into valid Fortran code and compiles, links, and runs them against the module under test.

FUnit is {opinionated software}[http://www.oreillynet.com/pub/a/network/2005/08/30/ruby-rails-david-heinemeier-hansson.html] which values convention over configuration. Specifically, fUnit requires a Fortran 95 compiler, it only supports testing routines contained in modules, it requires tests to be stored along side the code under test, and it requires that you follow a specific naming rule for test files.

• Documentation: http://funit.rubyforge.org
• Project Page: http://rubyforge.org/projects/funit

== Requirements

• A Fortran 90/95/2003 compiler (set via FC environment variable)
• {The Ruby language}[http://www.ruby-lang.org/] with the {RubyGems package manager}[http://rubyforge.org/projects/rubygems/]

== Installation

gem install funit

== Example

Suppose you have a module in gas_physics.f90 that contains a routine that returns viscosity as a function of temperature,

module gas_physics .. contains .. function viscosity(temperature) real :: viscosity, temperature viscosity = 2.0e-3 * temperature**1.5 end function .. end module

The tests of this module would be contained in gas_physics.fun, and might contain a test like,

.. beginTest viscosity_varies_as_temperature IsRealEqual( 0.0, viscosity(0.0) ) IsEqualWithin( 0.7071, viscosity(50.0), 1e-3 ) endTest ..

This brief fragment is all you need, the framework provides the rest of the trappings to turn this into valid Fortran code.

You would run the tests for the gas_physics module with the command,

funit gas_physics

which would transform your fragments contained in gas_physics.fun into valid Fortran code, create a test runner program, compile everything, and run the tests. A sample output would look like,

parsing gas_physics.fun computing dependencies locating associated source files and sorting for compilation g95 -o TestRunner gas_physics.f90
gas_physics_fun.f90
TestRunner.f90

gas_physics test suite: Passed 2 of 2 possible asserts comprising 1 of 1 tests.

== Support

Please send an email to {[e-mail]}[mailto:[e-mail]]

== License

FUnit is released under the NASA Open Source Agreement, which requests registration. If you would like to register, send an email to {[e-mail]}[mailto:[e-mail]?subject=fUnit%20Registration&body=%20%20%20%20%20%20%20Name:%20%0AInstitution:%20%0A%20%20%20%20%20%20%20City:%20%0APostal%20Code:%20%0A%20%20%20%20Country:%20] with your name, institution (if applicable), city, postal code, and country. See COPYING[http://funit.rubyforge.org/files/COPYING.html] for details.

== A Brief History

On October 4, 2001, Mike Hill (then of {Object Mentor}[http://www.objectmentor.com/], now of {Industrial Logic}[http://www.industriallogic.com]) visited {NASA Langley Research Center}[http://www.larc.nasa.gov] in Hampton, Virginia and gave a test-first design talk at the {Institute for Computer and Applied Sciences and Engineering (ICASE)}[http://www.icase.edu]. Copies of his slides are available at {icase.edu/series/MPP}[http://www.icase.edu/series/MPP/].

Mike spent the afternoon with Bil Kleb, Bill Wood, Karen Bibb, and Mike Park reasoning out how we might create a testing framework for Fortran 90 to use during FUN3D[http://fun3d.larc.nasa.gov] code development. By the end of the afternoon we had a working prototype based on the macro expansion techniques employed in Mike Hill's cpptestkit[http://sourceforge.net/projects/cpptestkit]. We quickly found C-preprocessor macros to be too restrictive and rewrote the framework in Ruby[http://www.ruby-lang.org].

== To Do

• Rename assertions to more consistent with other xUnits.
• Use 'test' keyword instead of 'beginTest' business.
• Don't add to test name during translation to avoid Fortran's 32-character limit on names.
• Add some command line options (especially clean), possibly using CmdParse[http://cmdparse.rubyforge.org].
• Add assertions that capture stops, warning messages, and other exits.
• Use Rails RDoc template for the documentation.
• Complete migration from CamelCase to snake_case for methods and variables.
• For compilation, use a makefile instead of a single, ordered command line.
• To increase portability, create a single, stand-alone executable with Erik Veenstra's RubyScript2Exe[http://www.erikveen.dds.nl/rubyscript2exe/].
• Make funit self-tests fail gracefully if Fortran compiler is not found.