Menu

#6 Unit Testing only supports one run

closed-fixed
nobody
PyF95++/STL (5)
9
2009-12-04
2009-12-04
No

This looks similar to an issue I hit when I did not put an id into the name of the enumeration block. Basically, only the newest occurrence survives as the old ones are overwritten.

The solution is to use str(id(self)) as a portion of the name. However, this interrupts whatever searches are called when the run template is instantiated and it finds all of the TestRunner blocks, causing it to throw an exception.

Discussion

  • David Car

    David Car - 2009-12-04
    • status: open --> closed
     
  • David Car

    David Car - 2009-12-04

    Actually, this wasn't the problem. The problem was in the PyF95++ script. All blocks within a template block obtain unique names in the global symbol table when the template is instantiated. The TestRunner() block is in a template block. Therefore, when you instantiate a test suite with the run<...> templated function, TestRunner() will get unique based on that instantiation. So, if you had run<myTest>(...), then in the global symbol table you have:

    'TestRunner|run|class_UnitTest|...'

    and the above run<myTest>(...) would result in the following being added:

    'TestRunner_myTest|run_myTest|class_UnitTest|...'

    So no name clash is possible unless you have to test modules with the same name (not a good idea!).

    The real problem was in PyF95++. If a STL.F90 file was not created, then PyF95++ failed to repopulate the global symbol table after instantiation of the templates which needs to be done in all cases. If your test happen to use one of the STL containers, then this wasn't an issue. But if you had a suite of test modules which never use any of the STL containers, then this bug would surface. So, indirectly this tracker found a big bug.

    It's been fixed and is in the repository. It will be in the 1.2.5 release shortly.

     
  • David Car

    David Car - 2009-12-04
    • status: closed --> closed-fixed
     

Log in to post a comment.