pFUnit

pFUnit copied to clipboard

By adding a label to cmake tests created with add_pfunit_ctest(), it will be easier for projects to run just unit tests (or exclude unit tests) when running ctest.

A project we are working on is looking to switch from a hacked version of FRUIT to pFUnit, and one of the things that fruit has is the subroutine, set_case_name. Is there a way to add a string label to a test with pFUnit?

EDIT: another thing I am seeing is that FRUIT provides more detail on the asserts, i.e. if a given function has multiple asserts it does some collection of those asserts. This goes against the JUnit design philosophy. But as is the case with research scientist/engineers the unit test frameworks get co-opted into doing larger than unit tests and having some nested test structure is nice, being able to have a collection of related tests that can be investigated in the event of failure rather than have all the tests be at the same level of reporting.

@kurtsansom I think there may be 2 or maybe 3 independent issues here, but I don't know much about FRUIT beyond its rough equivalence to pFUnit.

The issue I opened above is really just a CMake hack that I'd forgotten I'd even opened, and really has nothing to do with the testing framework. (Or rather more to do with CMake's CTest framework than pFUnit.) Could you describe how set_case_name is used in FRUIT so that I can get a better sense of what would be required in pFUnit.

I can understand the desire to collect multiple assertion messages from within a test, but by default asserts need to fail in order to ensure that subsequent statements don't segfault and such. But having said that, the only reason that the first assertion failure in pFUnit returns immediately is because the @assert* annotations are defined that way It is probably quite straight forward to add a different family of annotations that don't include the check+return logic. The hardest part would probably be to agree on how to spell such macros.

Possible annotations that occur to me off the top of my head:

• @check*
• @warnIfNot*
• @reportIfNot*

Not liking any of them overly much, but maybe with more sleep something will occur to me. Feel free to suggest your own alternatives/preferences.