もしかして!?VisualStudio CodeでApexクラスがデバッグできる??
VisualStudio Codeのコマンドパレットでsfdxに関するコマンドを眺めていたら、「Replay Debugger用のApexデバッグログを有効化」というのを見つけました。
これはもしや、VisualStudio CodeでApexクラスをデバッグできるのでは?と調査してみました。
これまでのApexクラスデバッグと言えばこれ
これまでApexクラスのデバッグと言えば、デバッグログです。
ApexクラスにSystem.debugでデバッグ文を埋め込み、デバッグログを有効にしてログを取得する方法です。
System.debug('登録した祝日の件数: ' + lstHoliday.size());
08:53:20.138 (180307702)|VARIABLE_SCOPE_BEGIN|[156]|lstHoliday|List<Holiday>|true|false
08:53:20.138 (180345054)|VARIABLE_ASSIGNMENT|[156]|lstHoliday|[{"Id":"0C05D0000008gFESAY","Name":"建国記念の日","ActivityDate":"2020-02-11T00:00:00.000Z","IsAllDay":true,"Description":"<!----------PlusOne (18 more) ..."}]|0x9bfdc4f
08:53:20.138 (180355214)|STATEMENT_EXECUTE|[158]
08:53:20.138 (180358969)|HEAP_ALLOCATE|[158]|Bytes:11
08:53:20.138 (180410098)|HEAP_ALLOCATE|[158]|Bytes:1
08:53:20.138 (180428363)|HEAP_ALLOCATE|[158]|Bytes:12
08:53:20.138 (180448957)|USER_DEBUG|[158]|DEBUG|登録した祝日の件数: 1
08:53:20.138 (180458924)|STATEMENT_EXECUTE|[160]
08:53:20.138 (180477512)|HEAP_ALLOCATE|[160]|Bytes:11
08:53:20.138 (180519177)|EXCEPTION_THROWN|[160]|System.AssertException: Assertion Failed: 祝日の件数が異なります: Expected: 1, Actual: 2
08:53:20.138 (180598348)|HEAP_ALLOCATE|[160]|Bytes:57
08:53:20.138 (180655748)|FATAL_ERROR|System.AssertException: Assertion Failed: 祝日の件数が異なります: Expected: 1, Actual: 2
Apexクラスの開発を始めて7,8年になりますが、ブレークポイントで止めて変数を確認できるとどんなに楽だろうと思い続けてきました。
VisualStudio CodeでのApexクラスのデバッグ
Salesforceの公式としては以下のドキュメントになります。
Apex Replay Debuggerの設定
.vscodeフォルダにlaunch.jsonを作成し、以下の定義を行います。
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Launch Apex Replay Debugger",
"type": "apex-replay",
"request": "launch",
"logFile": "${command:AskForLogFileName}",
"stopOnEntry": true,
"trace": true
}
]
}
ブレークポイントの設定
デバッグしたいApexクラスを開き、ブレークポイントを設定します。
チェックポイントの設定
チェックポイントを設定しておくと、Apexクラスを実行したときのヒープダンプが取得できます。
ブレークポイントだけだと、情報が不足する可能性があるので、チェックポイントを設定しておきましょう。
ブレークポイントを設定した行にカーソルを置き、コマンドパレットで「SFDX: チェックポイントの切り替え」を実行します。
チェックポイントが設定されているかは、デバッグに移動して、チェックポイントで確認できます。
チェックポイントを設定したら、チェックポイントの情報を組織にアップロードします。
コマンドパレットで、「SFDX: 組織のチェックポイントをアップデート」を実行します。
チェックポイントがアップロードされると以下のログが出力されます。
デバッグログを取得する
デバッグログの取得を開始します。
コマンドパレットで、「SFDX: Replay Debugger用のApexデバッグログを有効化」を実行します。
デバッグログが有効になるとステータスバーに以下のように表示されます。
デバッグしたいApexクラスを実行します。
以下はテストコードの実行ですが、LWCから呼び出すなど、Apexクラスを実行できればいいようです。
ログを取得するには、コマンドパレットで「SFDX: Apexデバッグログを取得」を実行します。
取得したいログを選択します。
ログが取得できました。
あれ?設定したブレークポイントでは止まらない??
取得したデバッグログを元にApexクラスの実行を再現
取得したデバッグログを元にApexクラスの実行を再現してくれるようです。
コマンドパレットで、「SFDX: 最新のログファイルでApex Replay Debuggerを起動」を実行します。
するとログが開き、実行が止まりました(止まったように見えます。)
このまま実行してみます。
おおぉ!ブレークポイントを設定したところで止まりました!!
Apexクラスの開発を始めて7,8年、願い続けてきたApexクラスの実行をブレークポイントで止めるがついに叶いました。
そして、変数もちゃんと参照することができます。
感動が止まりませんが、後始末
デバッグログは、一定の時間(15分?)が経つと収集が止まるようですので、そのまま放っておいてもいいのですが、コマンドパレットで「SFDX: Replay Debugger用のApexデバッグログを無効化」を実行すると止まります。
Apex Replay Debuggerに感謝の気持ちを伝えて止めましょう。
この記事が気に入ったらサポートをしてみませんか?