CDK Toolkit Libraryにおけるテストの考え方

2025/07/12（土）に開催された「AWS CDK Conference Japan 2025」における私のセッション「CDK Toolkit Libraryにおけるテストの考え方」の発表資料になります。 #cdkconf2025 #jawsug_cdk

https://jawsug-cdk.connpass.com/event/356357/

Transcript

1. CDK Toolkit Libraryにおける テストの考え方 2025.07.12 AWS CDK Conference Japan 2025 KDDIアジャイル開発センター 名古屋オフィス 鈴木 正樹
2. 1 KDDI Agile Development Center Corporation 自己紹介 ◼ 氏名：鈴木 正樹 ◼ 所属：KDDIアジャイル開発センター（KAG） 名古屋オフィス ◼ 役割：クラウドアーキテクト ＆ バックエンドエンジニア AWS（特にサーバーレスやInfrastructure as Code）が大好き。 好きなサービスはAWS LambdaとAWS CDK 主にJAWS-UG 名古屋 ＆ JAWS-UG CDK支部で活動 ◼ Certification： ◼ AWS Solution Architect Associate（2023） ◼ AWS Community Builder(serverless)（2023～） ◼ : @makky12（SUZUKI Masaki@クラウドエンジニア） ◼ Blog：https://makky12.hatenablog.com/
3. 2 KDDI Agile Development Center Corporation 本日のアジェンダ • 前提：CDK Toolkit Libraryについて • CDK Toolkit Libraryでのテストについて ◦ インテグレーションテスト（Integ-Test）について ◦ 単体テスト（Unit-Test）について • まとめ：CDK Toolkit Libraryにおける単体テストとインテグレーションテストの扱いについて ※ 「CDK Toolkit Libraryを動かしてみた」的なことは話しません。ご了承ください （後日どこかで話したい） ※ CDK Toolkit Libraryは絶賛業務で使用中です
4. 3 KDDI Agile Development Center Corporation 前提：CDK Toolkit Libraryについて
5. 4 KDDI Agile Development Center Corporation CDK Toolkit Libraryとは CDK Toolkit Libraryの概要 • 今までCLI（CDK CLI）で実施していたCDKの各種処理を、プログラムコードから実行可能な ライブラリ（2025/07/12現在、Node.js（TypeScript/JavaScript）にのみ対応） • 下記のようなメリットがある ◦ インフラライフサイクルの細かいハンドリング＆CDKソースとの統合＆エラーハンドリングなど ◦ インテグレーションテスト・一時的な環境での動作検証 ◦ コードベースによる型の恩恵・命名規則、セキュリティベースライン、コーディングルールの一元管理…など • このへんは@fossamagna氏が「Amplify Gen2から知るAWS CDK Toolkit Libraryの使い 方」でお話しされていると思うので、詳細は省略 • 以後、この資料ではCDK Toolkit Libraryを「CTL」と略記することがあります。
6. 5 KDDI Agile Development Center Corporation CDK Toolkit Libraryとは CDK Toolkit Libraryの概要 • 2025/07/05開催の「JAWS ミート 2025」にて「CDK Toolkit Libraryの紹介」という内容 でLTしましたので、詳しく知りたい方はそちらをご参照ください https://speakerdeck.com/smt7174/cdk-toolkit-librarynoshao-jie
7. 6 KDDI Agile Development Center Corporation CDK Toolkit Libraryでのテストについて
8. 7 KDDI Agile Development Center Corporation CDK Toolkit Libraryでのテストについて（前提） • 「テスト」といっても色々あるが、本セッションでは以下の2つについて扱う ◦ インテグレーションテスト（Integ-Test） ◦ 単体テスト（Unit Test） • 「インテグレーションテスト」とは「インフラ環境を実際にAWSにデプロイした後にAWS上 の対象リソース（Lambdaなど）を実行し、インフラとアプリロジックが正しいことを確認 するテスト」のこと ◦ Mockなどを作成する必要がなく、実際のリソース（S3, DynamoDBなど）を使用したテストができる • CDKにおけるテストの詳細は、AWS Hero 後藤さんがbuilders.flashにブログを寄稿してい るので、詳細を知りたい方はそちらを参照 ◦ https://aws.amazon.com/jp/builders-flash/202411/learn-cdk-unit-test/
9. 8 KDDI Agile Development Center Corporation インテグレーションテスト（Integ-Test）に ついて
10. 9 KDDI Agile Development Center Corporation インテグレーションテストについて • CDK Toolkit Libraryでは「インテグレーションテストの実行」が目的の1つとなっている 引用元：https://community.aws/content/2wm6TNpUlPMVgcvXVySywxWaO7T/build-custom-cli-s- deployment-automation-and-more-with-the-aws-cdk-toolkit-library
11. 10 KDDI Agile Development Center Corporation インテグレーションテストについて • CDK Toolkit Libraryでは、（CDK同様）テストランナーの機能は提供されていない • が「プログラムコードで書ける」ことを利用し、AWS SDKを使用することでインテグレー ションテスト（≒Lambda実行など）が可能になる ◦ 例えば「@aws-sdk/client-lambda」の「InvokeCommand」を使用する ◦ これが（プログラムベースで書ける）CDK Toolkit Libraryのメリット • インテグレーションテストの結果に応じた、様々なカスタム処理を柔軟に実装可能 ◦ （例）「テスト失敗時に、ロールバック処理を実行する」など ◦ これも（プログラムベースで書ける）CDK Toolkit Libraryのメリットの一つ（CLIではなかなか大変）
12. 11 KDDI Agile Development Center Corporation インテグレーションテストの実装例 ※実装のサンプルになります（他にもいろいろやり方はあると思います） • 下記の方法でLambda関数のARNを取得/設定し、CTL内でInvokeCommandを実行する // 例1：スタックの「出力」を使用する例 // CDK側で、Lambda関数のARNを「出力」に出しておく new cdk.CfnOutput(this, 'functionArn', { value: someFunc.functionArn, }); // CTLのコードにてスタック情報から「出力」のLambda関数の ARNを取得 const functionArn = stack.outputs['functionArn’]; // 上記で取得したLambda関数のARNをFunctionNameに 指定して、InvokeCommandを実行する const lambdaClient = new LambdaClient({}); const invokeCommand = new InvokeCommand({ FunctionName: functionArn, Payload: Buffer.from(JSON.stringify({hoge: ‘xxx’})), }); const res = await lambdaClient.send(invokeCommand); // 例2：Lambda関数名をどこかのソースで定義してexportする例 // どこかのソース(parameters.tsなど) で、Lambda関数名を定義して exportしておく export const FUNC_NAME = ‘hogeFunc’ // CDK側の定義で、上記exportされたLambda関数名をimportして、 Lambda関数のfunctionNameに定義する const hogeFunc = new NodejsFunction(this, ‘HogeFunc’, { functionName: FUNC_NAME, …, }); // CTLのコードでも上記exportされたLambda関数名をimportし、ARN文字列を作成 する。（リージョンとアカウント名はstack.environmentから取得可能） const functionArn = `arn:aws:lambda:${stack.environment.region}:${stack.environment.account }:function:${FUNC_NAME} `; // あとは例1と同様、上記で設定したLambda関数のARNをFunctionNameに指定し て、InvokeCommandを実行する const lambdaClient = new LambdaClient({}); const invokeCommand = new InvokeCommand({ FunctionName: functionArn, Payload: Buffer.from(JSON.stringify({hoge: ‘xxx’})), }); const res = await lambdaClient.send(invokeCommand);
13. 12 KDDI Agile Development Center Corporation 単体テスト（Unit-Test）について
14. 13 KDDI Agile Development Center Corporation CDK Toolkit Libraryでの単体テストについて • 先述の通り、CDK Toolkit Libraryではテストランナーの機能は提供されていない • インテグレーションテストと違い、単体テストツール（jestなど）はCLIコマンドからの実行 が前提となっている（CDK Toolkit Libraryのコードからは実行しない） • つまり基本的に、単体テストはCDK Toolkit Libraryとは分離されて実行される // 例えば、こんなコマンドになる(cdk-toolkit-library.tsはCDK Toolkit Libraryのソースとする) npm run test ts-node cck-toolkit-library.ts // npm-run-allなどでひとまとめに実行することはできるが、それぞれは独立して実行される // （「ctl」は「ts-node cdk-toolkit-library.ts」のエイリアスとする run-s test ctl
15. 14 KDDI Agile Development Center Corporation CDK Toolkit Libraryで単体テストを実施する • 「CTLと単体テストが分離されて実行される」ことそのものは、たいした問題ではない ◦ そもそもGitHub Actionsでは、単体テストとCDKの処理をstepで分離して実行しているわけだし • ただできる事なら「CDK Toolkit Libraryの処理の一つ」として、単体テストを実行したい ◦ 単体テストを含めた「デプロイライフサイクル」をCDK Toolkit Libraryソースでまとめて管理したい ↓ CDK Toolkit Libraryソースで単体テストを実施することはできないか？
16. 15 KDDI Agile Development Center Corporation CDK Toolkit Libraryで単体テストを実施する • Node.jsの「child_process.execSync」を使用する事で、CTLで単体テストの実行が可能 ◦ child_processs.execSyncは、Node.js上でシェルコマンドを実行することが可能なメソッド（※1） • 最初に単体テストを実行することで、単体テストの結果をCTLの処理に反映できる ◦ （例）テストがすべてpassしたときのみdeployを実施する、何かがfailしたらその後の処理を中止する、など ◦ jestの場合、failになったテストがあるとErrorをthrowしてくれるので、OK/NGの判定が行いやすい • execSyncを使用して単体テストをCTLソース上で実行するメリットデメリットは下記の通り ◦ 単体テストを含めたデプロイライフサイクルを、CTLソースで一元管理できる ◦ 単体テスト・synth・deployなどの各種処理を、1コマンドで実行可能（ts-node xxx.ts） ◦ 個々のテスト結果がわかりにくい（結果による色分けがされないので。頑張れば可能かもしれないけど…） ◦ あまり大量のテスト結果メッセージは処理できない（非ストリーミングによるメモリの限界） ※1: 他にもexec（非同期実行）、spawn（非同期実行＆ストリーミング出力対応）などがあります
17. 16 KDDI Agile Development Center Corporation 単体テストのCTLでの実装例 ※CTLソースコードで単体テストを実装するサンプルになります（importや定数定義などは省略） // CTLソースコードで単体テストを実装するサンプル // 単体テスト用の関数 function unitTest() { try { // execSyncで単体テストコマンドを実行 execSync('npm run test'); return NO_ERROR; } catch (error) { // テストがfailした場合、Errorがthrowされる。またその場合テスト結果はconsole.xxxがなくても出力される console.error('Error during unit test'); return WITH_ERROR; } } // CTLのメイン処理関数 async function main() { const toolkit = new Toolkit(); // ここで単体テストを実行 const testResult = unitTest(); if (testResult === WITH_ERROR) return; // 単体テストがpassした場合のみ、deployなどCTLでの各種処理を実行する（詳細は省略） const cloudAssembly = await createCloudAssembly(toolkit); await deployStack(toolkit, cloudAssembly, ‘MyStack’); }
18. 17 KDDI Agile Development Center Corporation まとめ：CDK Toolkit Libraryにおける 単体テストとインテグレーションテストの 扱いについて
19. 18 KDDI Agile Development Center Corporation CDK Toolkit Libraryにおける単体テストの扱いについて • CTLソース内で単体テストを行うことで「デプロイライフサイクルを一元管理できる」「1コ マンドで完結できる」などのメリットが得られる • ただし「個々のテスト結果がわかりにくい」「あまり大量のテスト結果メッセージは処理で きない」などデメリットもある • GitHub ActionsではStepレベルで単体テストとデプロイを分けるため、あえて「CTLソース に単体テストを含めない」という選択も十分ありえる • このへんは「運用がしやすい方」を選択するのが良い
20. 19 KDDI Agile Development Center Corporation CDK Toolkit Libraryにおけるインテグレーションテストの扱いについて • CDK Toolkit Libraryでは「インテグレーションテストの実行」が目的の1つとなっており、 AWS SDKの「InvokeCommand」などで実行することができる • 単体テストと違い「実際のAWS環境で動作確認する」事が可能なので、可能であれば何か1 つでもCTLソース内でデプロイ後に実行するのが理想（思わぬ不具合の発見につながる） • ただしCTLの実行環境（GitHub Actions/CodePipelineなど）で実行必要な権限（アクセス キー、ロールなど）を管理しておく必要があり、その手間が発生する • ただしそれでも 「実際のAWS環境で動作確認できる」メリットは大きいので、可能であれば、 何か1つでもインテグレーションテストは実行したほうが良い（と思う）
21. 札幌オフィス SAPPORO OFFICE 秋田オフィス AKITA OFFICE 高崎オフィス TAKASAKI OFFICE 金沢オフィス KANAZAWA OFFICE 舞鶴オフィス MAIZURU OFFICE 広島オフィス HIROSHIMA OFFICE 福岡オフィス FUKUOKA OFFICE 那覇オフィス NAHA OFFICE 仙台オフィス SENDAI OFFICE 東京本社 TOKYO MAIN OFFICE 三島オフィス MISHIMA OFFICE 名古屋オフィス NAGOYA OFFICE 大阪オフィス OSAKA OFFICE
22. 採用募集中！ エンジニア・デザイナー
23. Be a Change Leader. アジャイルに力を与え 共に成長し続ける社会を創る