https://github.com/abusalimov/clion-debugger-plugin-stub
Showcase for developing debugger tests using the CLion testing infrastructure in an external plugin
https://github.com/abusalimov/clion-debugger-plugin-stub
clion-plugin gdb intellij-sdk lldb
Last synced: 10 days ago
JSON representation
Showcase for developing debugger tests using the CLion testing infrastructure in an external plugin
- Host: GitHub
- URL: https://github.com/abusalimov/clion-debugger-plugin-stub
- Owner: abusalimov
- Created: 2023-07-03T13:04:15.000Z (about 3 years ago)
- Default Branch: master
- Last Pushed: 2023-07-04T12:46:22.000Z (about 3 years ago)
- Last Synced: 2025-03-22T10:43:03.678Z (over 1 year ago)
- Topics: clion-plugin, gdb, intellij-sdk, lldb
- Language: Kotlin
- Homepage:
- Size: 75.2 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# clion-debugger-plugin-stub
Showcase for developing debugger tests using the CLion testing infrastructure in an external plugin
## Overview
The key class is `com.jetbrains.cidr.execution.debugger.CidrDebuggerTestCase`,
if everything is set up correctly, it should be available in the test scope.
Debugger tests use a test project built using CMake. Before running the tests,
the infrastructure builds it and remembers marker lines for setting breakpoints
into a subclass of `com.jetbrains.cidr.CidrDebugProjectMarkup`. That particular
class is tied to the specific debug project.
There's two sets of tests:
- those inheriting from
`com.jetbrains.cidr.execution.debugger.CidrDebuggerDriverTestCase` - tests
for the debugger driver, they run without creating a debug session or
a CidrDebugProcess instance. It's easier to debug failures in these tests;
- and those inheriting from
`com.jetbrains.cidr.execution.debugger.CidrDebuggingWithDebugProjectTestCase` -
these are more like "integration" tests, with an XDebugSession,
CidrDebugProcess and stuff.
Both flavors of the tests usually set some breakpoint, run the test program with
certain arguments to trigger the breakpoint, and then probably inspect variables.
Both revolve around a blocking queue of events,
either `CidrDebuggingFixture.DriverEvent` or `CidrDebuggingFixture.DebuggerState`.