Qt Creator ManualTests DebuggerCdb: Difference between revisions
Jump to navigation
Jump to search
(Point to test projects and improve descriptions) |
(Added link to online installer) |
||
Line 1: | Line 1: | ||
[[Category:Tools::QtCreator::QualityAssurance]] | [[Category:Tools::QtCreator::QualityAssurance]] | ||
For the following tests, you will need to build projects on Qt using MSVC. You can get a suitable build of Qt from the official [https://download.qt.io/official_releases/online_installers/ Online Installer]. | |||
{| class="wikitable" | {| class="wikitable" |
Revision as of 11:38, 2 March 2022
For the following tests, you will need to build projects on Qt using MSVC. You can get a suitable build of Qt from the official Online Installer.
Test | Result | Annotation |
---|---|---|
Create new project. Can you build, run and debug it? | automated | |
Set breakpoint, press F5 to build and run debugger, verify that program stops at a breakpoint that you set:
|
||
Test breakpoint module resolution (see below) | ||
"Step into" a couple of times. Can you step into Qt source code (*.cpp file under QTDIR. You might need to configure source paths mapping under Tools -> Options -> Debugger -> Add Qt sources...)? | ||
Test debugging helpers: Do classes like QImage or std::string show beautiful information instead of the raw structure? | automated | |
Stop at a breakpoint with one initialized QString, std::string and int. Can you edit their contents in "Locals and Expressions" view? Will the program continue with these changed values? | ||
Step through some (not all) test* functions and check whether the displayed data looks sane | ||
Comment out the return statement inside the following functions one by one. Check whether you'll end up with a proper stack trace & locals display.
|
||
Test a breakpoint in a QThread:
|
||
Switch on temporarily 'Operate by Instruction' (small icon above the stack trace) and check whether you see disassembler output and can step by instruction |
Test | Result | Annotation |
---|---|---|
Check I/O (qDebug, std::cout, std::cerr), on Win for both Debug and Release. Please read the below note! | ||
Check "Run in Terminal". Use Terminal for input. | ||
Check nothing bad happens on a simple int main() {} program with no breakpoints set | automated |
Test | Result | Annotation |
---|---|---|
Check registering for post-mortem debugging:
|
||
Attach to a crashed process | ||
|
||
Test unusual situations: Kill X 'externally' while debugging (both in a 'running' and 'stopped' state), where X is
|
Breakpoint module resolution
- Set a new breakpoint in application code (say 'testapp').
- Right-click into the breakpoint view and make sure that "Use Tooltips (...)" is checked.
- Hover over breakpoint view, verify that 'Module' is empty in tooltip.
- Start the application, make it stop at breakpoint.
- Finish debugging, restart debugger. Should be faster now.
- Display tooltip of breakpoint again. Module should now be something 'testapp'.
stderr/stdout handling on Windows
- An application needs to be built with 'console' for stderr/stdout to appear (use Creator's "Run in terminal" setting)
- Creator itself is built with 'console' in debug mode only.
- qDebug() prints to stderr for 'console' apps, else to the Windows debugger log, which can be shown with the DbgView utility
- CDB will catch only qDebug() when app is built without ‘console’, rest goes to app console as with normal Windows app