---
sourceDocument: Xanadu API Reference
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/xanadu/api-reference

 Release :

    - xanadu

ft:locale :

    - en-US

ft:publication_title :

    - Xanadu API Reference

ft:clusterId :

    - crapiref

bundleId :

    - crapiref

workflow :

    - Creator


---

# JS Code Coverage Debug

# JS Code Coverage Debug {#ariaid-title1}

* Release version: Xanadu
* 
* Updated August 1, 2024
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read

The JS Code Coverage Debug application allows administrators and application developers to log the server-side 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 server-side 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.
{#js-code-coverage-debug__ul_oyd_fbg_5y}  
Note:  
The JS Code Coverage Debug application doesn't log information for client-side scripts.  
Figure 1. Sample code coverage highlighting

## JS Code Coverage highlighting {#ariaid-title2}

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.  
{#js-code-coverage-highlighting__table_utc_44l_5y__entry__2}

| 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. |
[Table 1. Meaning of code highlighting]

{#js-code-coverage-highlighting__table_utc_44l_5y}

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.
**Related concepts**   

* [Script Debugger and Session Log](https://servicenow-prod.fluidtopics.net/eFpTaSOE7boTyKwIcHQ5wQ "The Script Debugger enables users with the script_debugger role to debug server-side JavaScript. Users with the log_debugger role can use the Session Log to view and download required logs.")

## Activate JS Code Coverage Debug {#ariaid-title3}

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 AllSystem ApplicationsAll Available ApplicationsAll. {#activate-js-code-coverage-debug__find-plugins-cmd}
{#activate-js-code-coverage-debug__navigate-application}
2. Find the plugin using the filter criteria and search bar.  
   You can search for the plugin by its name or ID. If you cannot find a plugin,
   you might have to request it from ServiceNow
   personnel.{#activate-js-code-coverage-debug__p_cb1_nfg_h1c}
   {#activate-js-code-coverage-debug__find-plugin-cmd}
{#activate-js-code-coverage-debug__find-plugin}
3. Select Install to start the installation process.  
   Note:  
   When domain separation and delegated admin are enabled in an instance, the administrative user must be in the global domain. Otherwise, the following error appears: Application installation is unavailable because another operation is running: Plugin Activation for \<plugin name\>.
   You will see a message after installation is completed. For information about the components installed with a plugin, see [Find components installed with an application](https://www.servicenow.com/docs/access?context=find-components&version=xanadu&pubname=xanadu-platform-administration&ft:locale=en-US). {#activate-js-code-coverage-debug__activate-plugin}
{#activate-js-code-coverage-debug__activate-plugin}{#activate-js-code-coverage-debug__steps_rfx_bf1_2t}

### What to do next

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

* [List of Xanadu
  plugins](https://www.servicenow.com/docs/access?context=list-of-plugins&version=xanadu&pubname=xanadu-platform-administration&ft:locale=en-US)

## Debug with JS Code Coverage Debug {#ariaid-title4}

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

### Before you begin

Role required: js_coverage_debugger or admin

### Procedure

1. Navigate to AllJS Code Coverage DebugEnable Coverage.  
   The system logs which server-side 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 IncidentCreate New.
3. Trigger the server-side 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 DebugDisable Coverage.  
   The system stops logging script and code lines run.
5. Navigate to JS Code Coverage DebugCoverage Data.  
   The system displays the list of coverage data associated with the current user session.  
6. Select the script or transaction you want to review.  
   {#debug-with-code-coverage__table_grx_zxl_5y__entry__2}

   | 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 Name | Displays the transaction that called the script by thread ID and URI. |
   [Table 2. JavaScript Code Coverage fields]

   {#debug-with-code-coverage__table_grx_zxl_5y}  
   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.

*[\>]: and then