About the behaviour of CTEST_CUSTOM_PRE_TEST

Code
1

Hello,

Have a problem when using CTEST_CUSTOM_PRE_TEST to start a daemon. After the daemon started, ctest still wait it exit
For example I have a python daemon, when I run it by command python3 myDaemon.py, it returns to the shell prompt quickly, and the myDaemon.py work as a daemon. But it I set

set(CTEST_CUSTOM_PRE_TEST “python3 myDaemon.py")

The ctest blocks to wait it return and none of the tests starts running

I am wondering how could I change the behaviors of CTEST_CUSTOM_PRE_TEST, let it not block

I even tried to use execute_process and specify the INPUT_FILE, OUTPUT_FILE, ERROR_FILE, it will not block. How do I set similar options for the CTEST_CUSTOM_PRE_TEST

execute_process(
COMMAND python3 myDaemon.py
INPUT_FILE /Users/bzhu/PycharmProjects/httpDaemon/psql.in
OUTPUT_FILE /Users/bzhu/PycharmProjects/httpDaemon/psql.out
ERROR_FILE /Users/bzhu/PycharmProjects/httpDaemon/psql.err
RESULT_VARIABLE result
)

Thank you

2

@craig.scott would you happen to know more about CTEST_CUSTOM_PRE_TEST?

3

I don’t use it myself. For situations like this, I use test fixtures instead. I define a test case which starts up the server and another one which shuts it down. I define a fixture name (say DB). I set the startup test’s FIXTURES_SETUP property to the fixture name, the shutdown test’s FIXTURES_CLEANUP property to the fixture name, and any test that needs to access the server will list the fixture name in its own FIXTURES_REQUIRED property. See the FIXTURES_REQUIRED test property docs for examples.

I find the main wrinkle with the above is getting a platform independent way of starting a process in the background and leaving it running, then having a platform independent way for the shutdown test to robustly know what process it has to terminate and be able to do so. If you don’t care about supporting Windows, it isn’t too painful, but I would dread having to make this work across all major platforms. You may want to consider implementing the startup and shutdown steps in something like python to try to minimise the platform-dependent pain.