Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
experience with unit testing in fortran?
423 views
Skip to first unread message
mlo...@gmail.com
Jul 21, 2012, 8:11:43 AM7/21/12
to
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?
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?
Dan Nagle
Jul 21, 2012, 10:16:50 AM7/21/12
to
Hello,
Investigate pFUnit from NASA Goddard.
--
Cheers!
Dan Nagle
Investigate pFUnit from NASA Goddard.
Cheers!
Dan Nagle
mlo...@gmail.com
Jul 21, 2012, 2:09:20 PM7/21/12
to
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.
dpb
Jul 21, 2012, 2:46:46 PM7/21/12
to
On 7/21/2012 1:09 PM, mlo...@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??
--
> ... 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??
--
mlo...@gmail.com
Jul 21, 2012, 3:41:20 PM7/21/12
to
Maybe not the right term, but from the pFUnit user guide:
**
One complicating factor for assembling suites of tests in Fortran as opposed to some languages such as python and Java is the lack of “reflection”. Language features in Java and python allow a procedure to dynamically inquire about what methods are available in a given class, and therefore to automatically create a list of procedures that follow some naming convention for unit tests. The analogous feature in Fortran would be to use the language to create a list of procedures that are made available by a given Fortran module. In the absence of this convenience, we must use some external source-code analysis script to automatically detect and assemble our unit tests. (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 program (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 scripts they've provided that automates this (also not ideal, makes the build system a little weird, and dependent on external scripts outside of the language itself).
With gtest in c++ on the other hand, you simply write your test routines, and those get implicitly registered with the main testing routine. I *think* it does this through preprocessor macros, so it seems like it'd be possible 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
> apparently lacks??
>
> --
**
One complicating factor for assembling suites of tests in Fortran as opposed to some languages such as python and Java is the lack of “reflection”. Language features in Java and python allow a procedure to dynamically inquire about what methods are available in a given class, and therefore to automatically create a list of procedures that follow some naming convention for unit tests. The analogous feature in Fortran would be to use the language to create a list of procedures that are made available by a given Fortran module. In the absence of this convenience, we must use some external source-code analysis script to automatically detect and assemble our unit tests. (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 program (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 scripts they've provided that automates this (also not ideal, makes the build system a little weird, and dependent on external scripts outside of the language itself).
With gtest in c++ on the other hand, you simply write your test routines, and those get implicitly registered with the main testing routine. I *think* it does this through preprocessor macros, so it seems like it'd be possible 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
> apparently lacks??
>
> --
Dan Nagle
Jul 21, 2012, 4:12:28 PM7/21/12
to
Hi,
pFUnit is undergoing a redesign; if you have a specific requirement,
you might try to contact the developers.
--
Cheers!
Dan Nagle
you might try to contact the developers.
--
Cheers!
Dan Nagle
Arjen Markus
Jul 27, 2012, 12:18:10 PM7/27/12
to
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
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
mlo...@gmail.com
Jul 27, 2012, 5:53:54 PM7/27/12
to
Thanks. I've decided to go with interfacing to boost::test as it's well supported and mature.
0 new messages