CTest Debugging in VSCode

Per CTest registrierte Tests aus CMake können in VSCode auf viele unterschiedliche Arten und Weisen gestartet werden.

Und jede hat ihre individuellen Eigenarten.

Ignorieren wir mal die “Problemchen”, die uns CONAN einbrocken kann und sprechen wir nur über CMake.

Natürlich kann man ein Test-Programm-Target auch als normales CMake-Debug Target auswählen und ganz normal zum Debugging starten … doch darum soll es hier nicht gehen.

Wird ein Target als Test per add_test() registriert, erscheint der Test auch in VSCode’s Test Explorer.
Dort kann der Test per Klick gestartet werden, was CMake anwirft und dieses dann den Test regulär startet.

Neben dem Start-Pfeil-Button, gibt es noch den Start-Debugging Button neben jedem Test.
Beim einem Klick darauf braucht VSCode wieder eine Launch-Konfiguration, die in etwa so aussehen kann:

 // .vscode/launch.json
 {
   "version": "0.2.0",
   "configurations": [
     {
       "name": "(gdb) CTest Launch",
       "type": "cppdbg",
       "MIMode": "gdb",
       "request": "launch",
      "program": "${cmake.testProgram}",
      "args": [ "${cmake.testArgs}" ],
      "cwd": "${cmake.testWorkingDirectory}"
    },
    {
      "name": "(msvc) CTest Launch",
      "type": "cppvsdbg",
      "request": "launch",
      "program": "${cmake.testProgram}",
      "args": [ "${cmake.testArgs}" ],
      "cwd": "${cmake.testWorkingDirectory}"
    }
  ]
}

Beim “Start-Debugging” erscheint ein Menüs, das uns die beiden definierten Möglichkeiten anbietet und startet einen Debug-Prozess basierend auf den CTest-Einstellungen, die wir gewählt haben.

Und wenn diese Einstellungen falsch sind, startet gar nichts.

CMake Generator Unterschiede

Ein gravierenden Unterschied zwischen MSVC und den anderen Compilern ist die Visual Studio Solution, und ihre Projekte, die Debug und Release- Konfigurationen beinhalten, während für andere Compiler eine Konfiguration vorausgewählt werden muss.
Das führt dazu, dass ein GCC immer genau ein Ausgabeverzeichnis für Programme und Bibliotheken hat, doch Visual Studio erhält zwei, einmal Debug und einmal Release. Der add_test() Test muss also wissen, wie er Debug und Release-Konfigurationen unterschiedlich verwaltet.

Jetzt kommt noch ein weiterer Fall hinzu: nämlich Ninja.
Ninja-Build kann das Bauen wie MSBuild verwalten, verzichtet aber auf Solutions oder VS-Projekte und setzt das unkompliziertere GCC Schema mit genau einem vorkonfigurierten Build-Type ein.

Aus diesem Grund sieht meine add_my_test() Funktion so aus:

 set(APP_EXECUTABLE ${PROJECT_NAME})
 set(TEST_ARGS)
 get_target_property(OUTPUT_FOLDER ${TARGET_NAME} RUNTIME_OUTPUT_DIRECTORY)
 if(MSVC AND NOT (${CMAKE_GENERATOR} MATCHES "Ninja"))
   set(TEST_WORKING_DIRECTORY "${OUTPUT_FOLDER}/$<CONFIG>")
 else()
   set(TEST_WORKING_DIRECTORY "${OUTPUT_FOLDER}")
 endif()
 add_test(NAME "${TEST_NAME}" WORKING_DIRECTORY "${TEST_WORKING_DIRECTORY}" COMMAND "${APP_EXECUTABLE}" ${TEST_ARGS})

Fazit

Mit der Launch-Konfiguration für CTest und ein paar Anpassungen für den Start kann jedes Testprogramm auch aus dem VSCode Testing-Tab zum Debuggen gestartet werden.

Ich wünschte, ich hätte CTest und VSCode schon 10 Jahre früher kennen gelernt und eingesetzt, denn strukturiertes Testen kann die Qualität der Softwareentwicklung nachhaltig verbessern.