I'm a big advocate of test-driven development and unit testing in general, =
but I've been away from Fortran for a while and haven't used it there. I ha=
ve done a decent amount of TDD in C++ with boost::test and google's gtest. =
I've found a handful of testing fortran framework candidates from googling,=
 but information is pretty sparse and devoid of serious user feedback. I'm =
not seeing anything on this group on the subject from the last few years, s=
o I'm hoping to hear from someone with experience in this area. I'm using a=
 number of F2003 constructs, and I'm not seeing any information on those wi=
th the various testing frameworks (although I assume there's no issue when =
the testing suites are actually written in fortran.)


Fortran candidates:

FRUIT: Looks like it should work. Cons are no automatic test registration t=
o an executable, requiring "rake" to parse your test source into a main tes=
ting exe. Also appears to have just one maintainer doing all the work.


FUnit: Might work, no updates since 2009. Not seeing any documentation outs=
ide of three small canned examples, with some not-transparent syntax. Ruby =
dependency.

External candidates:

boost::test or gtest: Work well, are well supported, but I'd have to mainta=
in the glue of C++/Fortran interoperability, and I'm not sure how/if that w=
orks with fully fledged classes in F2003.

python's unittest: Similar issue as for a C++ testing framework of needing =
to maintain considerable interfaces. f2py chokes on modern fortran construc=
ts, so this could take considerable extra work.


Any thoughts/recommendations/experiences?

Hello,

Investigate pFUnit from NASA Goddard.

On 2012-07-21 12:11:43 +0000, mlohry@gmail.com said:

> I'm a big advocate of test-driven development and unit testing in 
> general, but I've been away from Fortran for a while and haven't used 
> it there. I have done a decent amount of TDD in C++ with boost::test 
> and google's gtest. I've found a handful of testing fortran framework 
> candidates from googling, but information is pretty sparse and devoid 
> of serious user feedback. I'm not seeing anything on this group on the 
> subject from the last few years, so I'm hoping to hear from someone 
> with experience in this area. I'm using a number of F2003 constructs, 
> and I'm not seeing any information on those with the various testing 
> frameworks (although I assume there's no issue when the testing suites 
> are actually written in fortran.)
> 
> 
> Fortran candidates:
> 
> FRUIT: Looks like it should work. Cons are no automatic test 
> registration to an executable, requiring "rake" to parse your test 
> source into a main testing exe. Also appears to have just one 
> maintainer doing all the work.
> 
> 
> FUnit: Might work, no updates since 2009. Not seeing any documentation 
> outside of three small canned examples, with some not-transparent 
> syntax. Ruby dependency.
> 
> External candidates:
> 
> boost::test or gtest: Work well, are well supported, but I'd have to 
> maintain the glue of C++/Fortran interoperability, and I'm not sure 
> how/if that works with fully fledged classes in F2003.
> 
> python's unittest: Similar issue as for a C++ testing framework of 
> needing to maintain considerable interfaces. f2py chokes on modern 
> fortran constructs, so this could take considerable extra work.
> 
> 
> Any thoughts/recommendations/experiences?


-- 
Cheers!

Dan Nagle

Thanks Dan, that doesn't look too terribly bad. I guess it's a lack of inspection in Fortran that prevents automatically registering tests. I managed to shoehorn pfUnit into a cmake build system, so this should work for me.

On 7/21/2012 1:09 PM, mlohry@gmail.com wrote:
> ... I guess it's a lack of inspection in Fortran...

OK, I'll bite...what, precisely, is a "lack of inspection" that Fortran 
apparently lacks??

--

Maybe not the right term, but from the pFUnit user guide:

**
One complicating factor for assembling suites of tests in Fortran as oppose=
d to some languages such as python and Java is the lack of =93reflection=94=
.. Language features in Java and python allow a procedure to dynamically inq=
uire about what methods are available in a given class, and therefore to au=
tomatically create a list of procedures that follow some naming convention =
for unit tests. The analogous feature in Fortran would be to use the langua=
ge to create a list of procedures that are made available by a given Fortra=
n module. In the absence of this convenience, we must use some external sou=
rce-code analysis script to automatically detect and assemble our unit test=
s. (Or, of course, simply assemble them manually.) Note that even with the =
extensions from the 2003 Fortran standard, developers will need to assemble=
 tests via some non-Fortran mechanism.
**

As it stands in pFUnit, you're required to either write your unit tests in =
a source file, and then also manually reference them in the main testing pr=
ogram (not ideal, because you may write some test and then forget to put it=
 into the main routine as well), or equivalently use a sequence of shell sc=
ripts they've provided that automates this (also not ideal, makes the build=
 system a little weird, and dependent on external scripts outside of the la=
nguage itself).=20


With gtest in c++ on the other hand, you simply write your test routines, a=
nd those get implicitly registered with the main testing routine. I *think*=
 it does this through preprocessor macros, so it seems like it'd be possibl=
e to do the same thing in fortran, but I really have no idea.



On Saturday, July 21, 2012 2:46:46 PM UTC-4, dpb wrote:
> OK, I'll bite...what, precisely, is a "lack of inspection" =
that Fortran=20
> apparently lacks??
>=20
> --

Hi,

On 2012-07-21 18:09:20 +0000, mlohry@gmail.com said:

> Thanks Dan, that doesn't look too terribly bad. I guess it's a lack of 
> inspection in Fortran that prevents automatically registering tests. I 
> managed to shoehorn pfUnit into a cmake build system, so this should 
> work for me.

pFUnit is undergoing a redesign; if you have a specific requirement,
you might try to contact the developers.

-- 
Cheers!

Dan Nagle

You might also have a look at ftnunit - part of http://flibs.sf.net.
It is a pure Fortran solution to unit testing (with a small exception:
a batch file or shell script to get the test program started and
running in the right mode and some optional Tcl utilities)

Regards,

Arjen

Thanks. I've decided to go with interfacing to boost::test as it's well supported and mature.

On Friday, July 27, 2012 12:18:10 PM UTC-4, Arjen Markus wrote:
> You might also have a look at ftnunit - part of http://flibs.sf.net.
> 
> It is a pure Fortran solution to unit testing (with a small exception:
> 
> a batch file or shell script to get the test program started and
> 
> running in the right mode and some optional Tcl utilities)
> 
> 
> 
> Regards,
> 
> 
> 
> Arjen



On Friday, July 27, 2012 12:18:10 PM UTC-4, Arjen Markus wrote:
> You might also have a look at ftnunit - part of http://flibs.sf.net.
> 
> It is a pure Fortran solution to unit testing (with a small exception:
> 
> a batch file or shell script to get the test program started and
> 
> running in the right mode and some optional Tcl utilities)
> 
> 
> 
> Regards,
> 
> 
> 
> Arjen



On Friday, July 27, 2012 12:18:10 PM UTC-4, Arjen Markus wrote:
> You might also have a look at ftnunit - part of http://flibs.sf.net.
> 
> It is a pure Fortran solution to unit testing (with a small exception:
> 
> a batch file or shell script to get the test program started and
> 
> running in the right mode and some optional Tcl utilities)
> 
> 
> 
> Regards,
> 
> 
> 
> Arjen



On Friday, July 27, 2012 12:18:10 PM UTC-4, Arjen Markus wrote:
> You might also have a look at ftnunit - part of http://flibs.sf.net.
> 
> It is a pure Fortran solution to unit testing (with a small exception:
> 
> a batch file or shell script to get the test program started and
> 
> running in the right mode and some optional Tcl utilities)
> 
> 
> 
> Regards,
> 
> 
> 
> Arjen