Script Background gives you a safe sandbox to verify your Script Include methods work correctly before attaching them to Business Rules or Client Scripts. You'll instantiate the class, call methods with test data, and log results to validate behavior.
Why you test Script Includes separately
Most Script Include bugs get discovered after they're already attached to a Business Rule or Client Script, which makes debugging painful. You're troubleshooting multiple layers — is the rule firing? Is the condition right? Is the Script Include broken? — instead of isolating the logic. Platform developers who skip this step end up cycling through rule modifications, trying to figure out why their custom methods aren't working, when the issue was in the Script Include all along.
How Script Background testing works
Script Background runs server-side JavaScript with full database access and no UI constraints. You instantiate your Script Include like any other JavaScript class, call methods with sample data that matches your real use case, and log the results with gs.info() to see what actually happened. The key is testing the edge cases — null values, empty strings, missing records — not just the happy path. Start with simple method calls and work up to complex scenarios that match your production conditions.
Building confidence in your code
Once basic testing passes, create test scenarios that match your actual implementation. If the Script Include will be called from an Incident Business Rule, test it with real Incident sys_ids. If it processes user input from a Service Catalog, test with the weird strings users actually submit. Good Script Include testing means you attach it to Business Rules with confidence, and when something breaks in production, you know the issue isn't in your custom methods.
Before you start
- •Script Include created and readable
- •admin role or elevated developer access
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Navigate to Script Background
Go to System Definition > Scripts - Background. You'll see a large text area for JavaScript code. This runs with full server privileges and database access, so treat it like a production environment.
Instantiate your Script Include
Create a new instance of your Script Include class by typing 'var myTest = new YourScriptIncludeName();' Replace 'YourScriptIncludeName' with the exact API name from your Script Include record. If your Script Include has initialize() parameters, pass them here.
Use descriptive variable names — if you're testing multiple Script Includes, 'incidentHelper' is clearer than 'test1'.
Call methods with test data
Call the methods you want to test with realistic parameters. For example, 'var result = myTest.processIncident("9d385017c611228701d22104cc95c371");' Use actual sys_ids from your instance when testing methods that query records. Chain multiple method calls if you need to test workflows.
Log results for verification
Use gs.info() to output results and intermediate values: 'gs.info("Result: " + result);' or 'gs.info("Record count: " + myTest.getRecordCount());'. Log both the final output and any intermediate calculations you want to verify. The logs appear in the System Log after execution.
Execute and check logs
Click 'Run script' to execute your test code. Navigate to System Logs > System Log to see your gs.info() output. Look for your logged messages and verify the results match expectations. If you see errors, they'll appear here with line numbers.
Test edge cases and error conditions
Run additional tests with null values, empty strings, and invalid sys_ids to verify your Script Include handles bad input gracefully. Call methods with the weird data users actually submit in production. Add gs.info() statements around error handling to confirm exceptions are caught properly.
Best practices
Never run destructive operations (updates, deletes, inserts) in Script Background on production instances — use a development environment or add conditionals to prevent execution.
Test with actual sys_ids from your instance data, not made-up values — this catches issues with ACLs and missing records.
Log intermediate values inside complex methods, not just final results — you need to see where logic breaks down.
Clear the Script Background field between test runs to avoid accidentally executing old code with new changes.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue