The Code Coverage tool provides information about which lines of code have been executed. This tool is useful during testing because it tells you whether the code coverage of your test plan is acceptable.
When you build a binary with code coverage instrumentation, the compiler inserts code that counts, at run time, each execution of a basic block. Execution of individual lines is not counted because the required instrumentation would adversely affect both the size and execution time of the binary. The basic block counts are gcov metrics and are sent by the binary to the qconn agent.
In this release, the IDE also uses the branch coverage metrics collected by gcov. These metrics include the number of times a branch was executed (which is really how many times the branch condition was evaluated), and the number of times each branch was taken. This second metric is quite helpful for ensuring that your tests cover every branch, which is essential for complicated programs.
When you launch an application with the Code Coverage tool enabled, the tool requests coverage data from qconn at regular intervals, as defined in the launch configuration. The IDE uses the block count data that it receives to calculate the line coverage for the program. To map code blocks to specific lines, the Code Coverage tool needs the notes (.gcno) files generated when the binary was built. Then, the IDE visually presents the line coverage data in a new code coverage session.
When you launch an application in Coverage mode, the IDE switches to the QNX Analysis perspective and in the Analysis Sessions view, displays a new session containing the coverage data for the running program. The session header contains the code coverage session icon (), the binary name, a session number (which gets incremented each time a program is run with any analysis tool that displays its results in this perspective), and finally, a timestamp showing the launch time.
Each code coverage session also has a Logs container that lists an XML-based log file (session.gcs), which stores details such as the session name, number, and start time.
A branch is any programming element that causes the code to not continue executing in a linear way. In addition to the obvious C/C++ branching constructs of if, else, for, while, and switch, the && and || operators introduce their own branches, and there may be others created by calls to inline functions or compiler optimizations.
You can view the data from any previous session by expanding it and examining the coverage percentages for its files and functions. If you don't see these components listed when you first expand a session, right-click it and choose Open.
The IDE writes the report as a set of dynamic HTML files. The main output directory stores the HTML root file and the supporting CSS, JavaScript, and icon image files. In a subdirectory named after the project, additional HTML files store the coverage results for source files and functions.
When you open a source file, there's a field, Source View, shown just above the code. This field lets you toggle between seeing all of the source code lines or only the uncovered lines. Clicking the latter setting lets you quickly see the areas of code missed by your test program. The Source View field isn't shown for functions; when you click a link to a function, you see only its code (with the coverage markup).
You can also add coverage data from included files to the report, by setting the right code coverage preference. When this preference is specified, the summary page has entries for functions in included files (in addition to those functions in the project source files).
If you leave the Include source files in report property at its default disabled setting, the IDE still generates HTML files containing the source code and line-by-line markup for files but not functions. You can access these HTML files in the subdirectory named after the project; there just aren't any links to them in the summary page.