Thank you for your feedback.
Form temporarily unavailable. Please try again or contact docfeedback@servicenow.com to submit your comments.
Versions
  • London
  • Kingston
  • Jakarta
  • Istanbul
  • Helsinki
  • Geneva
  • Store
Close

JS Code Coverage Debug

JS Code Coverage Debug

The JS Code Coverage Debug application allows administrators and application developers to log the scripts triggered during a user session and then review which lines of code the system ran.

Users with the js_coverage_debugger role can debug scripts without having to set breakpoints or review onscreen debug messages. Instead, the system saves script usage data in the JavaScript Code Coverage [sys_js_code_coverage] table. Each JavaScript Code Coverage record contains:
  • The user session that called the script
  • The script record the system called identified by table, sys_id, and script field
  • The script record the system called identified by type and name
  • The transaction that called the script
  • The start time of the transaction
  • The contents of the script field highlighted to indicate which lines the system ran
Figure 1. Sample code coverage highlighting

JS Code Coverage highlighting

The JS Code Coverage application highlights script fields to indicate whether the system ran or skipped each line.

Figure 2. Sample code highlighting

The color of the highlight indicates how the system evaluated the code line.

Table 1. Meaning of code highlighting
Highlight color Meaning
Green This is an executable line of code that the system ran during the session.
Red This is an executable line of code that the system skipped for some reason. The system may have skipped an executable line of code because the necessary script conditions were not met or because the script function was never called. You may want to use the Script Debugger to determine why the system skipped the line of executable code.
Gray This is a non-executable line of code such as white space, code comment, or a portion of an expression split across multiple lines that cannot run on its own.

Administrators and application developers can use this information to conduct more targeted debugging activities such as using the Script Debugger to determine why script conditions are not being met.

Activate JS Code Coverage Debug

You can activate the JS Code Coverage Debug plugin (com.glide.js.coverage) if you have the admin role.

Before you begin

Role required: admin

Procedure

  1. Navigate to System Definition > Plugins.
  2. Find and click the plugin name.
  3. On the System Plugin form, review the plugin details and then click the Activate/Upgrade related link.

    If the plugin depends on other plugins, these plugins are listed along with their activation status.

    If the plugin has optional features that depend on other plugins, those plugins are listed under Some files will not be loaded because these plugins are inactive. The optional features are not installed until the listed plugins are installed (before or after the installation of the current plugin).

  4. (Optional) If available, select the Load demo data check box.

    Some plugins include demo data—Sample records that are designed to illustrate plugin features for common use cases. Loading demo data is a good practice when you first activate the plugin on a development or test instance.

    You can also load demo data after the plugin is activated by clicking the Load Demo Data Only related link on the System Plugin form.

  5. Click Activate.

What to do next

To see the components the plugin installed, refresh the plugin form and select the Plugin Files related list.

Debug with JS Code Coverage Debug

Use JS Code Coverage Debug to record a user session and then review which scripts and lines of code the system ran.

Before you begin

Role required: admin or js_coverage_debugger

Procedure

  1. Navigate to JS Code Coverage Debug > Enable Coverage.
    The system logs which scripts and code lines the system runs as well as displays session debug messages in the JS Code Coverage namespace.
  2. Navigate to the table or page whose logic you want to test.
    For example, navigate to Incident > Create New.
  3. Trigger the script or scripts you want to test.
    For example, create an incident with an associate CI item to test several business rules.
  4. When you have completed testing, navigate to JS Code Coverage Debug > Disable Coverage.
    The system stops logging script and code lines run.
  5. Navigate to JS Code Coverage Debug > Coverage Data.
    The system displays the list of coverage data associated with the current user session.
    Sample JavaScript Code Coverage records
  6. Select the script or transaction you want to review.
    Table 2. JavaScript Code Coverage fields
    Field Description
    Script Name Displays the script run by table name, sys_id value, and script field.
    Script Reference Displays the script run by script type and name.
    Transaction Displays the transaction that called the script by thread ID and URI.
    For example, select the Script Reference Business Rule: incident events.
    The system displays the JS Code Coverage Debug record.
  7. Review the Script field to determine which lines of code the system ran.
    For example, the business rule added the incident.inserted event to the event queue.

Result

You determine which lines of code the system ran.

What to do next

Use the code coverage information to do more targeted debugging activities such as set breakpoints and review variable values with the Script Debugger.