Testing and debugging
The Momentics IDE for BlackBerry provides a source-level debugger that's integrated with the other workbench tools.
The Momentics IDE debugger uses the GNU Debugger (GDB) as the underlying debug tool. The Momentics IDE debugger translates each action in the UI into a sequence of GDB commands, and then processes the output from GDB to show the current state of the app being debugged. You can see and control the GDB commands by using the GDB consoles that are available in the Debug perspective in the Momentics IDE. You can also perform other debugging tasks, such as:
- Profile a QML project using the Cascades Profiler
- Profile a C/C++ project using the Application Profiler
- Measure code coverage for C/C++ projects
- Minimize memory usage in C/C++ projects
Keep reading to learn about the following topics:
- Debugging a C/C++ app
- Debugging a QML app
- Debugging headless apps
- Debugging with the console and editor
- Unit testing
If you are writing apps for the work space (that is, developing enterprise apps for an organization), see Testing and debugging apps in the work space.
The Debug view
In the Debug perspective, the Debug view shows the debugging session, tool, and thread instance, as well as the stack frames and controls for each device that you debug on. It displays the debugging information in a tree hierarchy. It shows stack frames as child elements and includes the reason for a suspension beside the thread. For example, a thread is suspended when it reaches the end of the stepping range, a breakpoint, or a received signal. When an app exits, the Momentics IDE also shows the exit code.
The thread label includes the thread's state. For example, the label might indicate that the thread is suspended because the app hit a breakpoint. You can't suspend only one thread in a process; suspension affects all threads. The number beside the thread label is a reference counter for the Momentics IDE, not a thread ID (TID) number.
Editing your source code after compiling causes the line numbering to be out of step because the debug information is tied directly to the source code. Debugging an optimized binary can also cause unexpected jumps in the execution trace, especially when the debug symbols for that library aren't available and loaded.
The following list provides examples of best practices for testing. For more information about the Built for BlackBerry checklists, see App Developer Checklist.
Stress test your app. Test your app under a high system load to ensure that it handles the high loads correctly.
Monitor app resources. Monitor files and devices that your app uses to ensure that it behaves as expected.
Test under various system states. Test your app under different system states, such as orientation changes, heavy stress conditions, and minimization, to ensure that your app behaves as expected.
Monitor CPU load and memory usage. Monitor CPU load and memory usage when your app is running and when in an inactive state to ensure that your app behaves as expected.
Last modified: 2015-05-07