テストと CI

テストに専用のビルドが必要な理由

高度な防御（VM Self Defending、VM Debug Protection、VM Domain Lock、およびそれらの基本版である selfDefending、debugProtection、domainLock）は、自分自身のエージェント、自動化ツール、デバッガーに対しても作動します。実行が停止したり、無関係なエラーが発生したり、誤った結果が生じたりする場合があります。disableConsoleOutput は、難読化したスクリプトだけでなくページ上のすべてのスクリプトについて、console のメソッドをグローバルに空の関数へ置き換えるため、ログに基づくアサーションは何も検出できなくなります。機能テストは、これらの機能を無効にした別のテスト用ビルドで実行してください。

機能テスト用の設定

テスト用の設定は共通の設定から派生させ、プリセットを選択したあとに次の上書きを適用します。これにより、Self Defending、Debug Protection、Domain Lock の VM 版と基本版がいずれも無効になり、disableConsoleOutput もオフになります（Low、Medium、High の各プリセットはこれを有効にします）。値は明示的に指定してください。オプションを省略すると、プリセットがそれを有効にしてしまう場合があります。

CI

まず元のコードを実行し、次に難読化したテスト用ビルドを同じチェックにかけます。失敗を再現できるよう、入力、実際に適用されたオプション、難読化ツールのバージョン、ビルド時の警告を記録してください。ダッシュボードと API の直接のレスポンスは、警告と解決されたバージョンを報告します。javascript-obfuscator パッケージは進行状況のメッセージでバージョンを報告しますが、警告は報告しません。

機能チェックに合格したら、本番用の元の設定から別途リリース用の成果物を生成します。その成果物そのものを、想定する実行環境で、許可されたドメイン上で、防御が検知対象とする自動化ツールやデバッガーを使わずに検証してください。テスト用ビルドが合格しても、保護されたリリースが検証されたことにはなりません。

ダッシュボード、javascript-obfuscator パッケージ（CLI または Node.js）、API のビルドでは同じ保護オプションが使われます。API でのテストには通常の認証情報とエンドポイントを使い、通常の使用量制限が適用されます。CI ではテスト用とリリース用の出力を別々のパスに置き、リリース用の成果物だけをデプロイしてください。

それでも実行に失敗する場合は、VM 実行時エラーの診断を参照してください。