VS Code Salesforce Extensions：Apexテスト実行での開発者の判断ミス

A. vs code salesforce extensions で実際にやらかした判断

私はSalesforce開発者として、Visual Studio Code と Salesforce Extensions が提供するGUI機能に、当初は絶大な信頼を置いていました。特にApexテストの実行に関しては、「IDEが全てをやってくれる」という幻想を抱いていた時期があります。右クリックメニューから「Run Apex Test」を選択したり、Test Explorerからテストクラスやメソッドを選んで実行したりする手法を、とにかく多用していました。

Apex Test の実行における誤算

GUIでの「Run All Apex Tests」の限界と無謀な試み

プロジェクトの初期段階、テストクラスの数がまだ少ないうちは、VS CodeのTest Explorerから特定のテストメソッドを実行したり、なんなら「Run All Apex Tests」を実行したりしても、そこまで大きな問題は感じませんでした。しかし、開発が進み、テストクラスが数百に膨れ上がり、各テストクラスの実行時間もそれなりに長くなってきた頃、私の判断ミスが顕在化し始めました。

正直言って、「Run All Apex Tests」をGUIから実行しようとすると、それはもう地獄のような時間がかかります。ひどい時にはタイムアウトすることもありましたし、Visual Studio Code自体がフリーズすることも珍しくありませんでした。当時は「PCのスペックが悪いのか？」「ネットワーク環境の問題か？」などと外部要因を疑っていましたが、今思えば、単にIDEの内部的な処理が大量のテストメタデータを捌ききれていなかっただけでしょう。この時に、「全てのテストをGUIから実行するのは、開発者の生産性を著しく阻害する無謀な行為である」と痛感しました。

特定のテストクラスやメソッドをGUIで実行することの限界

「Run All Apex Tests」がダメならと、次は特定のテストクラスやメソッドだけを選んでGUIから実行する、という方法に切り替えました。これは、修正を加えたコンポーネントに関連するテストのみを確認する場合には一定の効果がありました。しかし、これも完璧ではありませんでした。

Test Explorerの不安定さ: 時にTest ExplorerがApexテストクラスを認識しなかったり、最新の状態に同期されなかったりすることがありました。VS Codeを再起動したり、プロジェクトを再読み込みしたりする手間が発生し、それが頻繁だとかなりのストレスでした。
テスト結果の出力形式: テスト結果がGUI上に表示されるのは良いのですが、その後の処理（例えば、失敗したテストケースをまとめて報告書にするとか、特定のログだけを抽出するとか）が非常にやりにくいと感じていました。コピペで対応するのも限界があります。
デプロイ時のテストレベル制御の難しさ: 開発環境での手動テストならまだしも、本番デプロイ時など、特定のテストクラス群を指定して実行する必要がある場合、VS CodeのGUIからのデプロイでは、RunSpecifiedTestsのような細かいテストレベルの指定がしにくいと感じていました。package.xml を手動で修正してデプロイするにしても、CLIの方が断然楽です。

CLIへの回帰と最適化

これらの経験を経て、私はSalesforce CLI（sf コマンド）の重要性を再認識し、VS Code Salesforce ExtensionsのGUI機能とCLIを使い分けるべきだと結論づけました。特にApexテストの実行に関しては、CLIコマンドの柔軟性と安定性に軍配が上がります。

今ならこうする：CLIとVS Codeの使い分け

現在の私のワークフローは、以下のようになっています。

開発中の単体テスト実行:
ローカルで開発中のApexクラスやVisualforceコンポーネント、Aura/LWCコンポーネントを修正した場合、その変更に関連する特定のテストクラスやテストメソッドは、VS CodeのTest Explorerから手軽に実行します。これは、修正直後の動作確認には非常に便利です。GUIからの実行なので、直感的に結果を確認できます。
デプロイ前や広範囲なテスト実行:
複数コンポーネントにわたる変更や、デプロイ前のリグレッションテスト、あるいはCI/CDパイプラインでのテスト実行には、必ずSalesforce CLIの sf apex run test コマンドを使用します。
```
sf apex run test \
  --class-names "MyServiceTest,AnotherUtilTest" \
  --result-format human \
  --output-dir test-results \
  --wait 10
        
```
上記の例では、特定のテストクラスを指定して実行し、結果を human フォーマットでコンソールに出力しつつ、test-results ディレクトリに詳細な結果ファイルをJSON形式などで保存します。--wait オプションで待機時間も指定できるため、大規模なテストでもタイムアウトしにくくなります。

また、全てのテストを実行したい場合は、--code-coverage --synchronous オプションと組み合わせることで、より信頼性の高い結果を得られます。
```
sf apex run test \
  --code-coverage \
  --synchronous \
  --wait 60 \
  --result-format json \
  --output-dir coverage-results
        
```
これにより、テストの実行状況、カバレッジ情報、そして何が失敗したのかをプログラムから解析可能な形式で取得できるようになり、CI/CDとの連携が格段にしやすくなります。
本番デプロイ時のテストレベル指定:
本番環境へのデプロイ時に、特定のテストだけを実行する RunSpecifiedTests を利用する場合も、CLIの sf project deploy start コマンドが非常に強力です。
```
sf project deploy start \
  --source-dir force-app \
  --test-level RunSpecifiedTests \
  --run-tests "MyDeploymentTestClass1,MyDeploymentTestClass2" \
  --wait 30
        
```
当時はVS CodeのデプロイGUIで「Deploy Source to Org」を選ぶたびに、デプロイオプションの選択肢が限定的で、package.xml を手動でいじってからデプロイする手間が煩わしかった記憶があります。CLIであれば、コマンド引数で直接テストクラスを指定できるため、非常にスマートです。

これは当時の自分向けのメモだ。IDEのGUIは便利だが、常にそれが最善の選択肢とは限らない。特にスケーラビリティや自動化を考慮するなら、CLIの学習コストは払うべき投資だ。

にゃんこのSalesforce日記

このブログを検索