CoverageScanner is a C++ program that—in effect—replaces the usual compiler. It uses the native compiler’s preprocessor program to process the source code, then inserts instrumentation code into the preproecessed program, and at the end it compiles and links the project file, in the same way as in a normal build.
CoverageScanner’s instrumentation process consists of:
The compiler, linker and preprocessor that are used are from the native environment (gcc, Visual Studio, etc.). The Squish Coco tools are used transparently and the developer has only to prepend ’cs’ to the name of the compiler executable to activate the code coverage1. For example, using ’csgcc’ instruments the source code and uses the ’gcc’ compiler to generate objects.
Another way to achieve coverage is to add a wrapper directory to the search path. It contains compiler wrappers with the same name as the native tools. They are disabled by default but can be switched on with help of the COVERAGESCANNER_ARGS environment variable.
CoverageScanner works like a pre-processor which calls after instrumenting a source file the native compiler (Microsoft® cl.exe, GNU g++, …).
Several invocation method are possible:
CoverageScanner aims to work then as the native compiler with the difference that the code get instrumented.
Example:
Squish Coco provides also a replacement of the native compiler called wrapper which extends its command line argument to support the code coverage feature. To use it it is necessary to add at the first position in the PATH variable the path of CoverageScanner wrapper. The instrumentation get activated, when adding --cs-on to the command line argument.
Example:
Or, without modifying globally the PATH variable:
It is also possible to set the command line arguments of the wrapper using the COVERAGESCANNER_ARGS environment variable (see Chapter 9.1). In this case it is no longer necessary to modify the command line arguments.
Example:
Or, to instrument a complete project built using GNU make:
--cs-compiler specifies which native compiler should be used. All other command line arguments, except those specific to CoverageScanner, are passed through to the native compiler.
Example:
Compiler support is done with the help of a profile. It contains declarations which make it possible to adapt CoverageScanner to C, C++ and C# preprocessors, compilers and linkers.
For a description of the compilers that are currently supported see Chapter 47. For a description of the profile syntax see Chapter 50
Syntax:
| cs⟨compiler⟩ [⟨cs-options⟩] ⟨compiler arguments⟩ coveragescanner –cs-compiler=⟨STRING⟩ [⟨cs-options⟩] ⟨compiler arguments⟩ coveragescanner –cs-profile=⟨STRING⟩ [⟨cs-options⟩] ⟨compiler arguments⟩ |
where
For the use of --cs-compiler and --cs-profile see Chapter 9.2.9.
Example: cscl --cs-include=foo.h --cs-exclude=foo.h will exclude the header file foo.h from the coverage analysis.
CoverageScanner also reads options from the environment variable
COVERAGESCANNER_ARGS. The options must be separated by
spaces or tab characters (‘ ’ or ‘\t’). If both command
line arguments are present and the variable
COVERAGESCANNER_ARGS is set, the command line options
take precedence over the options in the environment variable.
This variable should only be set temporarily, e.g. in a script, because otherwise it would influence all builds.
The location of the temporary files that CoverageScanner generates can be changed by setting the environment variable SQUISHCOCO_TEMP_DIR to the path to another directory (see Chapter 46.3).
For a description of the coverage methods, see Part III.
This is the default if CoverageScanner is called directly or as a wrapper that starts with cs, like csgcc. If the wrapper has however the same name as the program (e.g. gcc), code coverage is by default switched off.
It is possible to have several --cs-on=⟨pattern⟩ and --cs-off=⟨pattern⟩ options. The last option that is matching decides whether code coverage analysis is enabled or disabled.
With this mode, the number of times an instrumentation point is executed is counted.
If this option is set, decision and condition coverage are automatically enabled too and full instrumentation mode (--cs-full-instrumentation) is switched on.
Most of the command line options that switch a certain coverage metric on also enable the data collection for other metrics. The following table shows which option enables which metrics.
Sometimes, the coverage measurements are also influenced by the option --cs-partial-instrumentation. For each of them, the table has two lines. The second line shows what happens when --cs-partial-instrumentation is present too. It is marked “(+partial)” in the table.
catch block of a try…catch
statement.
i == 3 and i == 4 are not distinguished.
If the option is not set, the two cases are counted separately.
The option influences the instrumentation of if
statements without an else part, like
Without the option, an invisible else branch is created
and its coverage is measured too. If the option is set, this is no
longer done and the coverage of the case in which cond
is false is no longer measured. The instrumented code then becomes
slightly smaller, which may be necessary on small embedded systems.
BOOST_FOREACH is not instrumented. (Enabled by default.)
Q_OBJECT,
qt_metacall, qt_metacast, …) . The code
behind the macro Q_FOREACH stays also uninstrumented. Qt
signals remain instrumented. (Enabled by default.)
Q_OBJECT, className, tr, …). Qt signals
remain instrumented. (Enabled by default.)
return statement of a lambda function.This brings a better support of lambda expression on Microsoft® Visual Studio® 2010. The option is only valid for C++11 compilers and Microsoft® Visual Studio® 2010. With a C compiler or an older C++ compiler, this option has no effect.
An exit function is a command that ends the control flow in a
function, like a return statement or the call of the
exit() function, or a function that always throws an
exception. Any code directly after such a statement is then
unreachable. With this option, it is possible to inform Squish Coco that
there are user-defined functions that have the same effect as
exit().
The option can be repeated; then several exit functions are declared.
#line
directives from the code generated by the preprocessor for
C++and C#.The preprocessor is called by the CoverageScanner before
instrumenting a file; afterwards the original compiler is called. On
some systems, compiling a file this way causes problems that do not
occur when the compiler is called directly. Removing the
#line statements then sometimes helps.
For each decision, a truth table is generated under Multiple Condition coverage and MC/DC. ⟨size⟩ is the maximal number of lines in the table. If a decision requires a truth table that is longer than ⟨size⟩, Squish Coco falls back to condition coverage for that decision.
The following options specify which files are included in the
code coverage. The options apply to files on the command line and to
those that are specified on #include statements.
One can use wildcards and regular expressions. In contrast to the common usage, the ‘*’ in wildcard expressions matches also the path separation characters. The syntax of regular expressions is described in Section 9.4.
Options accumulate. If more than one of the file inclusion/exclusion option is present, the last one that matches a given file determines whether it is included or excluded.
In the next options, name of the file in question is first converted to an absolute path.
Example: --cs-exclude-file-abs-wildcard=*.h
excludes all files with the extension .h.
Example: --cs-exclude-file-abs-regex=^.*\.h$
excludes all files with the extension .h.
Example: --cs-include-path=c:\include includes all
files located in c:\include.
Example: --cs-exclude-path=c:\include excludes all
files located in c:\include and its subdirectories.
Examples for complex inclusion patterns:
The following options refer to the name
under which a file occurs in an #include statement or on
the command line.
File paths and wildcard expression are converted to a canonical form
which does not contain ‘.’, ‘..’, or a duplicated path
separation character. (A ‘..’ at the beginning is however not
removed.) On Microsoft® Windows, characters are also converted to lower
case and every slash (‘/’) is replaced with a
backslash (‘\’).
Regular expressions are untouched. It is e.g. necessary to ensure that they do not contain duplicated path separators.
Example: --cs-include-file-wildcard=../include/*.h
includes all files with the extension .h located in the
directory ../include/ and its subdirectories.
Example: --cs-include-file-regex=^\.\./include/[^/]*\.h$
includes all files with the extension .h located in
../include/.
Relative file names are computed relatively to the current working
directory. For example, depending on the working directory one has to
use different parameters in order to inhibit the instrumentation of a
file src/test.c: If one is outside the directory
src, one may use
but when switching to src, the parameters must change:
Example: --cs-include-function-wildcard=C::* includes all
members of the class C.
Example: --cs-exclude-function-wildcard=*::Get* excludes all members of any classes which starts with Get.
If more than one of these inclusion/exclusion option is present, the last one that matches a given function determines whether it is included or excluded.
The following option works indepentent of the previous ones:
.csexe is added
automatically.By default, ⟨string⟩ has the value “%F” and
CoverageScanner uses the application name without the path as name
for the .csexe file.
The value of ⟨string⟩ may be an absolute path, like
“/my/dir/%F”. The directories in this path must already
be present when the instrumented program runs, since
CoverageScanner does not create them by default.1 Otherwise, ⟨string⟩ is
interpreted as a path relative to the working directory at the time
the program starts.
⟨string⟩ may contain several format specifiers. The values of the following specifiers are computed at compile time:
The values of the following format specifiers are computed at runtime:
main() function is started. If the current
working directory changes, this path remains identical.
.csexe file during its generation.
⟨function⟩ is specified according to the C++ convention. This
means that A::foo stands for the function foo
insider the A namespace or class. By default, the save
function that is called when ⟨triggerfunction⟩ runs is
__coveragescanner_save(), but it can be changed with the
following switch.
⟨savefunction⟩ must be a function without parameters, since it
replaces __coveragescanner_save(). Squish Coco automatically
inserts a declaration for ⟨savefunction⟩ at the beginning of
each source file. This makes it possible to define
⟨savefunction⟩ in a file that is compiled with
--cs-custom-library-source
(see Section 9.2.8).
The options are appended and become the content of $LIBGEN$, a variable that may occur in the replacement text for the profile option COMPILER_CMD (see Chapter 50.4).
If used in the form “--cs-library-after=-lmylib”, the
linker parameter for the CoverageScanner library will be inserted
directly after the option -lmylib.
With the dynamic type, Squish Coco can better handle Boolean expressions that contain non-Boolean objects with overloaded true and false functions. Dynamic types are however only available for Microsoft® Visual Studio® 2010 and later; for earlier C# versions, this option is needed.
static char %S[%I].
The following placeholder are available:
malloc() call fails.
The prototype of the
function should be ’void func(int size)’ and should not return.
The parameter size is the requested memory size passed as argument of the malloc() function.
This permits to catch an out of memory issue of the CoverageScanner’s code through a custom function.
The instrumentation tables are internal arrays generated by Squish Coco which contain the counter variables for code coverage.
Yes”.
Environment.Exit is called.
/noconfig.
The option has an effect only for the instrumentation of C or C++ programs. The code in ⟨file⟩ must then be written in the same language.
This is to include larger pieces of code into the instrumented code for a program without the need to change the sources of the program. The result is that code in the program can use the functions defined in ⟨file⟩. But note that the new functions still need to be declared in the source files that use them.
When however ⟨file⟩ is used to define the ⟨savefunction⟩ that is set by --cs-coverage-save-function=⟨savefunction⟩ (see Section 9.2.8), an explicit declaration is not necessary.
Example: --cs-profile=%SQUISHCOCO%\cl.cspro is equivalent to --cs-compiler=cl on Microsoft® Windows.
$ARCHITECTURE$ in the replacement text for the profile
parameter PREPROCESSOR_CMD
(see Chapter 50.3). The target architecture
is also used to select alternate profile parameters
(see Chapter 50).
.cspch are not generated.
This files are only used to enhance the compilation speed when using precompiled headers.
CoverageScanner also activates the instrumentation if some symbols are present in the command line option. This allows you to instrument
code from an IDE which does not permit adding custom command line options to the compiler or linker.
Example: Defining COVERAGESCANNER_COVERAGE_ON is equivalent of adding --cs-on to the command line.
Regular expressions are composed of items (see table 9.1 for the full list) and combining operators. These can be:
[…]: The brackets are used to define a set of characters.
For example, [123] corresponds to the characters
1, 2 or 3. It is possible to define a range
using the minus sign: [a-z] corresponds to all characters
between a and z.
[^…]: The caret defines a set of characters which should not match.
For example, [^0-9] corresponds to any character except a digit.
?: The question mark after a regular expression item makes it optional. ab? matches the string a or ab.
+: The plus operator makes it possible to repeat the regular expression item. ab+ matches every strings ab…b.
*: The star operator after a regular expression item signifies that the
item is optional and can be repeated. ab* matches every string ab…b and a.
|: The pipe operator specifies an alternative. a|b matches the character a or b.
(…): The parenthesis groups expressions into sub-expressions. (true)|(false) matches the string true or false.
\).
Element Description Equivalence Reverse Element ^The caret marks the beginning of the string. For example, ^c:will only match file names with an absolute path on the driveC:. If you wish to match a literal^you must escape it by writing\^.$The dollar marks the end of the string. For example \.cpp$will match every C++ file name. If you wish to match a literal$you must escape it by writing\$.\<Match the start of a word. \>Match the end of a word. .Any character \Escape character. Example: \.corresponds to the character ’.’ and not any character\mAlphanumeric character [0-9a-zA-Z]\M\aAlphabetic character [a-zA-Z]\A\bBlank character [ \t]\B\cControl character \C\dDigit [0-9]\D\gPrintable character except space []\G\lLower-case character [a-z]\L\pPrintable character \P\nPrintable character except space or alphanumeric character \N\sWhite-space characters (space, form-feed , newline , carriage return , horizontal tab and vertical tab) [ \f\n\r\t\v]\S\uUppercase letter [A-Z]\U\xHexadecimal digits [0-9a-fA-F]\X\wAlphanumeric character or underscore [0-9a-zA-Z_]\W
Table 9.1: Non ASCII Regular Expression Items
The CoverageScanner library is generated during instrumentation and enables the user
The library functions are accessible from any instrumented file,
without the need for an #include directive. When a file is
instrumented, a preprocessor symbol __COVERAGESCANNER__
is defined: It can be used to exclude calls to the library functions
from the compilation when instrumentation is switched off.
Syntax:
| void __coveragescanner_install(const char *appname) |
Initialize the CoverageScanner library. It should be the first
function call in the main() function. The parameter
appname contains the name of the executable. It is used to set
the name of the measurement file to ⟨appname⟩.csmes.
__coveragescanner_install() registers an exit handler via
atexit() in order to save the execution report whenever the
application terminates. The handler calls the function
__coveragescanner_save() to store the execution traces at
the end of the program. It is called when the program terminates
regularly and also if the signals SIGABRT, SIGTERM,
SIGFPE, SIGILL, SIGINT, SIGSEGV and
SIGTERM are received.
Suggested usage:
With gcc, clang or Microsoft® Visual Studio®, CoverageScanner automatically installs a minimal handler. It saves the execution in the file ⟨program_name⟩.csmes on a normal exit of the application. Calling __coveragescanner_install() allows setting the file name of the execution report and also saves the report at an abnormal exit, like a crash or an interrupt by a signal.
__coveragescanner_install() is not available for a compiler if its profile parameter CUSTOM_SETUP is set to NONE (see Chapter 50).
Syntax:
| void __coveragescanner_testname(const char *name) |
Set the name of the current test. It will be saved in the execution report and be displayed in the "Executions" window (see Chapter 19.1) when the .csmes file is loaded into CoverageBrowser.
All code that is executed until the end of the program or the next call of __coveragescanner_save() is considered part of the test name. If tests get the same name, CoverageBrowser disambiguates them by numbers, like “MyTest (2)”.
Test names may be hierarchical, with hierarchy levels separated by
slashes: If a program defines two tests, “group/test1” and
“group/test2”, CoverageBrowser displays them as two
tests, “test1” and “test2” under a common heading,
“group”.
Syntax:
| void __coveragescanner_teststate(const char *state) |
Set the state of the current test. The parameter state may have
the following values:
If the function is called twice, the first state is overwritten. The test state will be saved in the execution report and be displayed in the "Executions" window (see Chapter 19.1) when the .csmes file is loaded into CoverageBrowser.
Syntax:
| void __coveragescanner_add_html_comment(const char *comment) |
Set an HTML comment to the current execution. There is only one HTML comment active at any time, but it can be put together with several calls of __coveragescanner_add_html_comment(). In this case, the values of the various comment parameters are concatenated.
The full comment must follow the HTML syntax, but only the content
of the <body> tag is used. A minimal comment might therefore be
something like “<html><body>My comment</body></html>”.
Syntax:
| void __coveragescanner_clear_html_comment() |
Remove the comment added by calls of the function __coveragescanner_add_html_comment().
Syntax:
| void __coveragescanner_save() |
Save the execution report and reset the status of all instrumentations. The coverage counters for each line of code and the execution status of the current test are reset, but the HTML comment stays unchanged.
Syntax:
| void __coveragescanner_clear() |
Reset the coverage counters for all lines of code.
This is useful in a unit testing framework. After the framework has started, __coveragescanner_clear() can be called. Then the activity of the framework at startup does not become part of the code coverage.
Syntax:
| void __coveragescanner_filename(const char *name) |
Set the file name of the execution report. The extension
’.csexe’ is added automatically. If name is
NULL, the generation of execution reports is disabled.
name may contain the following escape sequences:
The escape sequences are only available for a compiler if its profile parameter FILE_FORMAT_SPECIFIER is set to YES (see Chapter 50).
Date and time may not be available on some embedded platforms.
Syntax:
| const char * __coveragescanner_get_filename() |
Function which returns the ’.csexe’ file name.
Syntax:
| int __coveragescanner_register_library(const char *library_name) |
Register a shared library that was loaded on demand. The function must
be called after a library has been loaded with dlopen() (UNIX®)
or LoadLibrary() (Microsoft® Windows). After it is registered,
the code coverage of the library is saved in the same coverage report
file as the coverage of the main application.
It is possible to call __coveragescanner_register_library() more than once, but every call must be matched by a corresponding call of __coveragescanner_unregister_library(). For each library there is a use counter to keep track of the registrations.
Returned values:
__coveragescanner_register_library() and __coveragescanner_unregister_library() are not available for a compiler if its profile parameter PLUGIN_REGISTRATION_API is set to NO (see Chapter 50).
Syntax:
| int __coveragescanner_unregister_library(const char *library_name) |
De-register a shared library that was loaded on demand. The function
must be called before a library is unloaded with dlclose()
(UNIX®) or CloseHandle() (Microsoft® Windows).
Returned values:
Syntax:
| void __coveragescanner_register_squish() |
Try to register the instrumented application with Squish. This makes most of the Squish Coco library functions accessible to Squish, so that it can control the writing of the coverage measurements.
It is rarely necessary to use this function explicitly since it is automatically called at start of the application (or by __coveragescanner_install(), if calling it is necessary).
Calling the function more than once has the same effect as calling it once. If the application was not started by Squish, the function has no effect.
Syntax:
| void __coveragescanner_set_custom_io( char *(*csfgets)(char *s, int size, void *stream), int (*csfputs)(const char *s, void *stream), void *(*csfopenappend)(const char *path), void *(*csfopenread)(const char *path), void *(*csfopenwrite)(const char *path), int (*csfclose)(void *fp), int (*csremove)(const char *filename) ) |
Define your own set of I/O functions.
Parameters:
size - 1 characters from
stream and store them into the buffer pointed to by s.
Reading stops after an EOF or a newline is read. If a newline
is read, it is stored in the buffer. A ‘\0’ is stored after
the last character in the buffer.s to stream,
without its trailing ’\0’.path for appending
text at the end.path for reading.path for writing.fp.filename from the file
system.By default, CoverageScanner writes the execution report (the
.csexe file) to the file systems with help of common C library
functions. In some situations, e.g. with embedded systems, it is
necessary to use other methods. For this reason, CoverageScanner
provides __coveragescanner_set_custom_io(), which lets you replace
the I/O functions used by __coveragescanner_save().
Default implementation:
Examples are available in Chapter 38.
CoverageScanner library is generated during the link process and enables the user to:
Additionally CoverageScanner sets the preprocessor symbol __COVERAGESCANNER__ which excludes this function from a normal compilation.
Syntax:
| void CoverageScanner.__coveragescanner_init() |
CoverageScanner.__coveragescanner_init() initialize explicitly the CoverageScanner library. Calling this function is only necessary on C# DLL which are not calling the static module initializer automatically.
Syntax:
| void CoverageScanner.__coveragescanner_testname(string name) |
CoverageScanner.__coveragescanner_testname() sets the name of the test which is currently being executed. It will be saved to the execution report and is displayed in the "Executions" window (see Chapter 19.1) when the loaded in CoverageBrowser.
Syntax:
| void CoverageScanner.__coveragescanner_teststate(string state) |
CoverageScanner.__coveragescanner_teststate() sets the state of the test which is currently being executed.
The string parameter state can have the following values:
It will be saved to the execution report and is displayed in the "Executions" window (see Chapter 19.1) when the loaded in CoverageBrowser.
Syntax:
| void __coveragescanner_memory_pool_stat(int *size, int *used, int * max_used ) |
__coveragescanner_memory_pool_stat() permits to retrieve the current memory consumption of the memory pool.
The following parameters are returned:
This function makes only sense in the case of using a memory pool.
Syntax:
| void __coveragescanner_add_html_comment(string comment) |
__coveragescanner_add_html_comment() append a comment to the current execution.
The comments needs to follow the HTML syntax but only the body is parsed. (The contents of the “<HEAD>” tag is ignored).
This function can be called several times, in this case the content is appended.
Syntax:
| void __coveragescanner_clear_html_comment() |
__coveragescanner_add_html_comment() clear comments added using void __coveragescanner_add_html_comment(string comment).
Syntax:
| void CoverageScanner.__coveragescanner_save() |
CoverageScanner.__coveragescanner_save() saves the execution report and resets the status of all instrumentations.
Syntax:
| void CoverageScanner.__coveragescanner_clear() |
CoverageScanner.__coveragescanner_clear() resets the status of all instrumentations.
Syntax:
| void CoverageScanner.__coveragescanner_filename(string name) |
this function sets the file name of the execution report. The extension ’.csexe’ is added automatically.
Syntax:
| void CoverageScanner.__coveragescanner_set_custom_io( __cs_fgets_delegate cs_fgets, __cs_fputs_delegate cs_fputs, __cs_fopenappend_delegate cs_fopenappend, __cs_fopenread_delegate cs_fopenread, __cs_fopenwrite_delegate cs_fopenwrite, __cs_fclose_delegate cs_fclose, __cs_remove_delegate cs_remove) |
Parameters:
public delegate string __cs_fgets_delegate(System.IO.Stream stream) csfgets reads in at most one less than size characters from
stream and stores them into the buffer pointed to by s.
Reading stops after an EOF or a newline. If a newline is read, it is
stored into the buffer. A ’\0’ is stored after
the last character in the buffer.public delegate void __cs_fputs_delegate(string s, System.IO.Stream stream) csfputs writes the string s to stream, without its trailing ’\0’.public delegate System.IO.Stream __cs_fopenappend_delegate(string path) csfopenappend open the file path for writing at the end.public delegate System.IO.Stream __cs_fopenread_delegate(string path) csfopenread open the file path for reading.public delegate System.IO.Stream __cs_fopenwrite_delegate(string path) csfopenwrite open the file path for writing.public delegate void __cs_fclose_delegate(System.IO.Stream fp) csfclose function will flush and close the stream pointed to by fp.public delegate void __cs_remove_delegate(string n) csremove removes filename from the file system.CoverageScanner writes the execution report (.csexe file) into file using the common C# file IO functions.
In some situations, for embedded systems for example, it is necessary to use an other way for recording it.
For this reason, CoverageScanner provides
CoverageScanner.__coveragescanner_set_custom_io() which replace the IO
functions used by CoverageScanner.__coveragescanner_save().
Sometimes it is necessary to apply CoverageScanner settings only to certain regions of the source code, e.g. to exclude parts of a file from instrumentation.
Several methods to do this are described in this chapter.
Source code annotations are specific comments which let you select source code parts to validate. Two kinds of annotations exist:
Source code annotations can directly be edited with CoverageBrowser or generated by writing specific comments into the source code.
To generate comments for a single source line it is only necessary to start a C or C++ comment with the keyword “coco:⟨comment⟩”. This will insert a comment for all instrumentations in the current line.
Example: In the following example, the comment “To test the failure, change the current working directory to a read-only directory” will be added to the instrumentations of the line 4.
Comments can also be generated for multiples source lines using the keywords “coco begin:⟨comment⟩” and “coco end”.
Example: In the following example, the comment “To test the
failure, change the current working directory to a read-only directory” will
be added to the instrumentations of the lines of the function write_log().
Manually validated instrumentation can be generated with a comment in the code that starts with the keywords “coco validated: ⟨comment⟩”. The ⟨comment⟩ will later occur in the coverage report. To validate a multi-line region of code, one can use the keywords “coco begin validated: ⟨comment⟩” and “coco end”. In order to be compatible with PureCoverage adjustments, CoverageScanner also recognizes “purecov:” line comments with the keywords “inspected” or “tested”, or alternatively “begin inspected”/“begin tested” and “end inspected”/“end tested” for multi-line annotations.
Example: In the following example, the comment “This function
does not need to be tested, only used for debugging.” will be added to the
instrumentations of the function write_log().
Note that the “coco end” comment is placed after the end of the function. This is because Coco measures code coverage of a function at its very end, there where the final closing brace is located. When we want to mark a complete function a covered, we need to include the last closing brace in the region between the manual validation comments.
Including the function header by placing the “coco begin” comment in front of the function is however not important.
CoverageScanner defines C and C++ pragmas to control the instrumentation during the compilation. All control pragmas are handled in a stack: They are valid until the end of the source file or until a #pragma CoverageScanner(pop) is encountered.
The pragmas have the following syntax:
#pragma CoverageScanner ( string )
or: __pragma ( CoverageScanner ( string ) )
or: _Pragma ( "CoverageScanner ( string )" )
List of supported pragmas:
switch statement.
switch statement.
CoverageScanner defines C# extensions of the #region
keyword which, at compile-time, controls the generation of the instrumentation.
The #region extension has the following syntax:
#region CoverageScanner ( string )
The keyword #endregion restores the generation options.
List of supported regions:
switch statement.
switch statement.
