Testing and CI
Use a separate configuration for functional tests when your test tools would trigger advanced defenses. There is no separate testing endpoint or dashboard environment.
Why tests need their own build
Advanced defenses (VM Self Defending, VM Debug Protection, VM Domain Lock, and their basic counterparts selfDefending, debugProtection and domainLock) also act against your own agents, automation, and debuggers. They may stop execution, throw unrelated errors, or produce incorrect results. disableConsoleOutput replaces console methods with empty functions globally, for every script on the page, not only the obfuscated one, so log-based assertions see nothing. Run functional tests against a separate testing build with these features turned off.
Functional test configuration
Derive the testing configuration from your shared settings and apply these overrides after selecting a preset. They disable the VM and basic versions of Self Defending, Debug Protection, and Domain Lock, and turn disableConsoleOutput off (the Low, Medium and High presets enable it). Pass explicit values; omitting an option can let a preset enable it.
CI
Run the original code first, then run the obfuscated testing build through the same checks. Record the input, effective options, obfuscator version, and build warnings so failures can be reproduced. The dashboard and direct API responses report warnings and the resolved version; the javascript-obfuscator package reports the version in its progress message but does not report warnings.
After functional checks pass, generate a separate release artifact from the original production settings. Validate that exact artifact in its intended runtime, on an allowed domain, without automation or debuggers that its defenses are designed to detect. Passing the testing build does not validate the protected release.
Dashboard, javascript-obfuscator package (CLI or Node.js), and API builds use the same protection options. API testing uses the usual credentials and endpoint, and normal usage limits apply. In CI, keep test and release outputs in separate paths and deploy only the release artifact.
If execution still fails, see Diagnosing VM Runtime Errors.