【登壇資料】 re:Growth 2025 大阪で「Step Functions（TestState API）から始めるローカルテスト戦略」というタイトルで登壇しました！#AWSreInvent
こんにちは。クラウド事業本部の桑野です。
2025/12/10 に開催された AWS re:Invent 2025 ふりかえり勉強会 re:Growth 2025 大阪 で「Step Functions（TestState API）から始めるローカルテスト戦略」というタイトルで登壇しました。
使用したスライドと登壇内容を本ブログにて共有します。
スライド
自己紹介
本題に入る前に自分語りをさせていただきます。
ジョインブログで書いていないことを一つお話ししました。
好きなAWSサービスとre:Inventの参加歴ですね。
前者は「API Gateway WebSocket API」です。
私は前職ではフロントエンド・バックエンドをメインに携わっておりましたので、AWSやインフラはほとんど触ったことがないような人間でした。
そんな中、ある日、業務で双方向通信の仕組みが必要になり、ありがたいことにリーダーから「やってみないか？」と声をかけてもらったことがきっかけで本サービスを触り、AWSやインフラに興味を持つことになりました。
最初に構築したAWSリソースということで特別な思い入れがあります。
後者については、一度も参加したことがありません。
来年は参加したいなという思いでre:Growthの運営も担当しました。
本編
冒頭
いきなり私から参加者の皆さんに「Step Functionsのテストをやっていますか？」と問いかけました。
参加者47名中、お一人の手が挙がっていました。私はてっきり1人も手が挙がらないと思っていたので、すごく動揺してしました。同時に素晴らしいな〜と感心もしていました。
手を挙げてくださった参加者の方、心の底から感謝します。ありがとうございました！
Step Functionsに限らず、テストやテストコードに対するよくある反応としては、以下の3つの通りかなと考えています。
- デプロイして動くかどうかを確認する
- テストする暇があるなら機能開発を優先する
- テストがそもそも必要でない（と考えている）
ただ、私は本当にそれで良いのかなと考えています。
今回はStep Functionsのアップデートを切り口に、テストのあり方を考えてみました。
Step Functionsとは
アップデートに触れる前に、そもそもStep Functionsとはどういうサービスなのかについて簡単に紹介しておきます。
- AWSサービスを複数組み合わせたワークフローを作成できる
→AWSインフラをイメージしづらい方向けには、AWSサービスをプログラミング言語でいう「関数」に置き換えて見てねという意味を込めてスライドを作っています。 - データのI/Oを加工する仕組みがある
- 各ジョブ（ワークフローを構成する一つの単位）毎にエラーハンドリングを組み込める
- 条件分岐や状態遷移の管理ができる
条件分岐やエラーの仕組みなどがあり、考慮すべき部分が沢山あることから、私はStep Functionsにはテストが必要だと考えました。
プログラムを作ると、分岐とかエラーハンドリングとかはもちろん、クラスや関数実装する場合なんかはI/Oの型定義とかしますよね。
この辺の動作を保証するために効率よく確認する手段としてテストコードというものがあったりします。
実はStep Functionsにもしっかりとテストするための機能が備わっています。
それが2年前、2023年のre:Inventで発表された「TestState API」というものです。
TestState APIの歴史
2023年re:Invent
Step Functionsのワークフローから単一のステートのみを個別で実行し、テストができるようになりました。
専用のAPIである「TestState API」から実行ができます。
ただし、この頃は制約があります。
テストではステートに組み込まれているAWSサービスを実際に動かすということに関係します。
実際に動かすということは、そのAWSリソースのデプロイが必要です。
動かすものによっては、時間がかかりますし、費用もかかってくる可能性があります。
Step Functionsの定義自体を確認したいのに、依存リソースが必要になるという部分から、スライドでは「結合テスト」と表現しました。
2025年pre re:Invent(11月)
そんな悩みを抱える中、re:Inventの約半月前、アップデートが発表されました。
それがTestState APIのMock機能の追加です。
これにより、依存リソースが必要ない単体テストができるようになりました。
アップデートの内容は3つあると考えており、その内容を紹介しています。
一番の目玉はMockのサポートです。これにより、依存リソースを気にせずにAPIを実行できるようになりました。
依存リソースを動かすためのIAM権限も不要となります。
※ただし、TestState APIをリクエストするための権限が必要なことには注意が必要です。
2つ目、3つ目は全ステートとエラーパターンの検証ができるようになったという点です。
これらはMockのサポートによって実現できるようになったのではないかと予想しています。
結局何が変わったのか
Step Functionsで何を確認したいかというと、大きくは3つあると考えています。
- 意図したI/Oの加工ができるか
- エラーハンドリングが機能するか
- 条件分岐が正しいか
アップデートが来るまでは、以上の3点を確認出来なくはないのですが、確認したい部分以外の準備がセットで必要となります。
それが今回のアップデートで以下のように変わります。
- デプロイが不要
- リソースにアクセスしない
- お金はかからないし、検証時間も削減できる
- 狙ったテストケースの再現が簡単
要するに 関心が綺麗に整理された と考えています。
Step Functionsのテスト戦略を考えてみる
Nano Banana Proを使ってテストピラミッドのイメージを作成してもらいました。
（自分の手が平気で5本ぐらい増えたような感覚になれます。）
「一番下層の単体テストを充実させ、上2つの複雑なテストができるだけ少なく済むようにしましょう」という考え方をStep Functionsにも当てはめてみました。
アップデートが来る前は上二つのテストは実施できる状況でした。
アップデート後は一番の土台である単体テストができるようになったことで、テストピラミッドのすべての構成要素が揃いました。この方針をベースにテストを組み立てていくと良いのではないかと考えています。
単体テストで検証したいポイントを考えてみる
単一ステートで検証できそうなポイントをNano Banana Proでイメージにしてみました。
私はStep Functionsの流れがRPGに近いのかなと思っていましたので、それを元に指示して作りました(笑)
絵では
- 入り口のデータ変換の部分ができている？
- エラーケースはどうする？
- 最終的にどのステートに向かって出力は何になるか？
というのを表現しようとしています。
伝えたかったこととしては、「Step Functionsもプログラミング言語で作成したコードと同じように単体テストができるよ」ということです。
お好みのテストライブラリ、例えばVitestやpytestなどに組み込んで気軽に実装できます。
プルリク前のテスト実施やCI / CDに組み込む難易度も下がったのではないかと考えています。
ただ、何よりも嬉しいのは、テストにかかる金銭的・時間的・労力的コストを一律で削減できるという点です。
これらを踏まえると、Step Functionsの開発体験が劇的に変わります！
まとめ
今回のアップデートで実現できることは以下の通りです。
- ローカルテストが実施できるようになる
- ステートの定義を検証できるようになる
- CI / CDへの統合も簡単になる
- 開発時間を短縮できる
インフラの知識は特別必要ありません。
TestState APIを実行する権限と、Step Functionsに対する好奇心、あとは「やってみようという気持ち」があればすぐに試せます。
ぜひ使ってみていただければと思います。
今回はASLやテストライブラリの実装例を紹介することはありませんでしたが、今後Vitestを使ったTestState APIのMockの実装してみた例なんかもご紹介できればなと思います。
お礼
初めての登壇ということもあり、緊張でマイクの電源をつけずに自分の声量だけで発表を始めようとしたりでお恥ずかしい姿をお見せしてしまいました。
終始緊張しっぱなしで落ち着きのない時間ではありましたが、手を挙げてくださったり、頷いてくださったりと反応ひとつひとつに嬉しさを感じました。
今回で満足せずこれからも定期的に発信していきますので、出会った際には声をかけていただけると幸いです。
現地に来てくださった参加者の皆様に改めて感謝を申し上げます。平日のど真ん中にご参加いただきありがとうございました。
参考
AWS Update Blog
AWS Docs
