ctest: best approach to portably run two or three applications concurrently

Hello,

I’d like to run two or three applications concurrently via ctest to test out our code that facilitates the interactions between the applications.

My current approach is using execute_process and multiple COMMANDs. This works for the most part, but is a bit of a kludge as we don’t need/use the stdoutstdin pipes. From what I can tell, I’m hitting the SIGPIPE error described in this Stack Overflow post

when/if COMMAND i exits before COMMAND i+1.

Any suggestions for alternative, and portable, mechanisms to run concurrent applications, or ways to disable to usage of pipes in execute_process would be appreciated.

Thank you.

It sounds like you want CTest’s fixtures feature. See the FIXTURES_REQUIRED property for more.

Thank you for the link to the fixtures docs. I also reviewed this blog post.

I see that fixtures lets you control the ordering of tests and provide a mechanism to avoid running dependent tests of tests that fail (and getting incorrect failure reports). Test concurrency is mentioned, but only in passing as a potential execution mode for tests that don’t have defined orderings.

Can you expand a bit on the use of fixtures for explicitly running multiple applications concurrently? Is the idea to define two tests in a fixture and then tell ctest to run tests concurrently (via ctest -j #)? Hopefully, I’m just overlooking something simple.

Thank you.

Fixtures define dependencies between tests. You don’t need to run ctest in parallel to get what you’re after. You do need to define your fixtures in a way that allows applications to continue running after tests finish though, which isn’t so straightforward.

The fixture setup tests would start the application(s) your main test(s) depend on. The fixture cleanup tests would then shut down those application(s). Unfortunately, doing that is platform-specific, and you have to think about things like applications left running from an earlier test run, how to not kill a process with the same name started somewhere else, etc. This ends up making your application startup and shutdown scripts a bit complex if you want them to be fully robust. You can do simple versions to get up and running, but after using fixtures for a while, you’ll likely run into the sort of scenarios I mentioned.

1 Like

Thank you @craig.scott . I appreciate the detailed response.

I’ll try having ctest run a bash script with a wait statement to avoid the complexities of separate setup and cleanup commands.