Unit Testing in f90

Hi!

I'm wondering if anyone is using unit test driven development for f90?
What supporting software are you using, and how do you go about
implementing the tests?

I'm kinda new to both f90 and unit testing. What I'm doing is writing
a test driver for each "unit" (usually a procedure or function), and
then USE-ing the module containing the code to be tested in the driver.

This causes a problem when I have private functions in the module,
since they can't be accessed from the test driver! As far as I can
tell the only way to get around this is to include the tests in the
module itself. Is this a reasonable option? It seems to have the
divantage of cluttering the final build with a bunch of dead code,
or would the linker take care of this?  What other options are there?

Thanks
Neilen

--
you know its kind of tragic
we live in the new world
but we've lost the magic
-- Battery 9 (www.battery9.co.za)

Neilen Marais wrote:
> Hi!
>
> I'm wondering if anyone is using unit test driven development for f90?
> What supporting software are you using, and how do you go about
> implementing the tests?
>
> I'm kinda new to both f90 and unit testing. What I'm doing is writing
> a test driver for each "unit" (usually a procedure or function), and
> then USE-ing the module containing the code to be tested in the driver.
>
> This causes a problem when I have private functions in the module,
> since they can't be accessed from the test driver! As far as I can
> tell the only way to get around this is to include the tests in the
> module itself. Is this a reasonable option? It seems to have the
> divantage of cluttering the final build with a bunch of dead code,
> or would the linker take care of this?  What other options are there?
>
> Thanks
> Neilen
>

I have found it very useful to have tests that can be left in the code
and turned on or off at will. The old "if (debug)" type control
where debug is initially just a parameter and then with a bit more
work makes it up to a data controlled variable. I often have test
drivers separate from the final code so that I can exercise things
more directly.

Having the unit test around is helpful when the functionality is
extended but does not work (It never happens* but I have a form letter
to explain that it doesn't. ;-) ). Then one can turn the tests on to
see where the trouble can be localized. Sometimes it turns out that
there is a problem that the tests did not detect so having the test
around to be strengthened is a bonus. Having current tests is a big
advantage. I expect to find some number of bugs are actually in the
unit tests as I don't have the problem well enough thought through
before coding it.

In the days when 16k was a common memory and 64k was large the issue of
dead code was a concern. Now with 128M video buffers it is not so much
of an issue. Not all problems are friendly enough to permit the test
code to be kept lurking about so you will have to find a solution
for your situation.





There is an old joke to the effect that hotels do not have bed bugs and
have form letters to explain that they do not have bedbugs to prove it.