Unit testing

I started yesterday with creating a GP extension, and I’m reading a bit (oiutside the GP website) about CTest, which can be used for unit testing CMake, used by GP extensions.

However, I get the error ‘No tests were found!!!’

I’m sure it’s something stupid, I never used CMake let alone CTest before.

I added these four lines to CMakeLists.txt, just before the last install command inside CMakeLists.txt:

add_executable(tester tester.cpp)
add_test(Tester tester)
target_link_libraries(tester PRIVATE ${PROJECT_NAME})

And I created in the main folder of the (Visual Studio CMake) project, a file tester.cpp.

Does anyone know how to fix it, or has maybe on GitHub some example with testing I can copy from, or can I best use StackOverflow for this ‘generic’ problem?

I can’t help, I’m sorry. I’ve never used CTest. Is your extension that complex that you need something like this? My testing is manual, with logging.

Did you get a basic version of your extension working?

1 Like

Thanks for answering.
It’s not necessarily complex, but since I’m using an MVC pattern it gets a bit complicated, especially to setup up the entire framework.
And since I want to add a lot, I will be backfired if I have to run it via GigPerformer.

It’s not that I want to make a full test set, but that I can easier test (one time) specific flows (against crashes).

I didn’t get a basic version working, just spend a couple of hours, so most conversion has to be done.

Meanwhile I found a kind of tricky way not using CTest, but ‘injecting’ some commands. But still I would prefer CTest also to get working, just in case.
However, I will ask that on StackOverflow as it is a more generic question.

Hi @Michelkeijzers,

the code snippet itself looks fine to me. What directory are you executing ctest in? It should be something like /path/to/your/project/build/Release.

On a more general note: What your code instructs CTest to do is: Run the binary produced by the tester target. If the binary returns exit code 0, a test case called Tester has succeeded. Most likely, for unit testing, you would use some framework, e.g. GoogleTest. For that case, CMake has special “library” functions to register each unit test that you write as its own CTest test case, which would make CTest quite a bit more useful than being a standardised way to running a single binary. GoogleTest’s CMake quickstart instructions are quite good in my opinion - and for more information, you can take a look at the reference documentation for CMake’s GoogleTest module.


That was the problem (I was running it from the command line that I got after starting it up via VIsual Studio code, but I had to change to the build\windows-native directory :-).

GoogleTest was my next thing to do (will do that next week). Thanks for your links, they will be helpful to reach to incorporate GoogleTest :-).

@simon Hope you don’t mind I postpone GoogleTest for a bit (or longer). As I found an easy way to just empty-stub the GP SDK functions, and being able to debug this way (not directly in GigPerformer, but as a standalone C++ console application). Whenever I need GoogleTest, I will recheck your post again.

That sounds interesting, I can see a use for that in the extension I am developing to enable easier development of the GUI without having to restart GP each time I want to test a change.

Is it something you can share?

Sounds like he just created a class with empty implementations of every GP function

1 Like

Yes, although it’s a bit tricky (not to share, but the solution).

I use two repositories:

  1. michelkeijzers/global_rackspace_cpp: Global Rackspace extension for Gig Performer, written in C++ (github.com)
  2. michelkeijzers/global_rackspace_cpp2_tester (github.com)

The first project is the actual extension (code), based on the example cpp SDK, and thus on CMake.
The second project the second is the ‘test’ code, or actually a Windows executable to test out something, which is a C++ Windows Console project.

The projects need to be on the same parent folder as the test project uses a relative paths to all the source code (except for one test class and the ‘stubbed’ gig performer SDK files). In the stubbed files, e.g. the logConsole function prints out to the screen instead of the log file. Also I had to use some preprocessor #if’s, to load the correct stub file.

When adding new source code, the test solution has to be manually changed to add the new source code (via the relative path).

1 Like

Kind of yes, except for some functions to log not to the console window but to the standard output.