Change Ctest to no longer run and kill gaia_db_server

[simone-gaia]

The fact that ctest was running and killing gaia_db_server, was not ideal but acceptable. Unfortunately, after introducing the new benchmark framework, the gaia_db_server instance run by ctest interferes with the instance run by the benchmarks.

For this reason, I decided to remove the CTestCustom.cmake logic.

• Remove the CTestCustom.cmake that runs and kills the server.
• Adapt the SDK tests to run and kill the server themselves.
• Disable Java & Python tests that rely on the running server.
• Move Java stuff into its own folder.

[LaurentiuCristofor]

Can't you just have some standard tests start a default Gaia server instance and then execute the Python/Java wrapper tests against it? This would be a bit like how we execute the FDW tests, except here you'd just have to execute the Python/Java test applications without worrying about passing in any parameters.

NOTE: edited for clarity.

[simone-gaia]

Not sure if I understand what you mean. Yes, we can definitely run the server as part of those tests, I didn't want to spend time on it now.

[LaurentiuCristofor]

What I mean is that it should be possible to execute these as you do the SDK tests.

I.e.:

• in the google test setup, you launch the server instance, like you do for the SDK tests.
• in the google test function, you execute the Python/Java test programs using system and just check for its return value. See verify_command_output helper in test_fdw.cpp, for example. And by executing the Python/Java test programs, I am thinking of running commands like python test.py and java Test.java.

Does this make more sense now?

[LaurentiuCristofor]

You could execute the Python/Java tests in this same way, right?

[simone-gaia]

Yes, I tried with Java, got some problems, and thought it was easier to disable the tests altogether.

[LaurentiuCristofor]

What problems did you encounter with Java?

What about Python? If you could keep at least one of those tests around, it would be better than not keeping either of them.

[simone-gaia]

I didn't try with Python. With Java, the problem was something related to the path to the server. I can try tomorrow. I have created a workaround to unlock #1481.

[LaurentiuCristofor]

Probably, the Java executable runs with the current directory being set to something else than the build folder?

I wouldn't want to disable support for these tests unless it's absolutely a pain. But the tests are so simple in their setup that it should be possible to keep them around - the only thing they needed is the default db instance, so if you're removing it from the test command and placing it into the test suite setup, that should already cover most of the challenge - we should just need to wrap the execution of the tests into a standard google test function.

[LaurentiuCristofor]

Can't we fix the Python/Java tests just like you did the SDK ones?

[daxhaw]

Changes to test_sdk* look fine.

[LaurentiuCristofor]

If my request to keep the wrapper tests working is too complicated, go ahead and merge these changes as they are. But if you can at least keep one of the tests around, I think it would help to have some coverage for the low-level DB API. Thanks!

[simone-gaia]

If my request to keep the wrapper tests working is too complicated, go ahead and merge these changes as they are. But if you can at least keep one of the tests around, I think it would help to have some coverage for the low-level DB API. Thanks!

It was simple at the end of the day. Instead of running the server from within the test (which is a little more complicated), I managed to run the server from the CMake command that adds the tests.