コドモン Product Team Blog

株式会社コドモンの開発チームで運営しているブログです。エンジニアやPdMメンバーが、プロダクトや技術やチームについて発信します!

テストがあれば、無限に挑戦できる🔥

この記事は、コドモンAdvent Calendar 2025 23日目の記事です。

こんにちは! コドモンでエンジニアをしている浦中です。

昨年産休に入り、今年の9月に復帰しました。外で車を見つける度に「ぶぶ!」と指差す子どもを見ては、サンタさんに大量の車のおもちゃをお願いしてしまいそうになる日々を過ごしています。

さて、2025年の12月といえば他でもない、AWS Lambda でPython 3.9のサポートが終了する月ですね。 私たちのチームでもバージョンアップを行いました。今回、ちょっとした振り返りをアドカレとして残すことにしました。シュトーレンをつまむおともとして気軽に読んでください!

これを読んだ人の、「テスト……面倒だなあ〜〜〜」という気持ちが少しでも軽くなれば幸いです。

なにしなきゃいけないの〜〜〜

私は Lambda や Python を業務でしっかり扱ってきたことがなく、ほぼ初学者の状態から対応に着手することになりました。

とりあえず Claude Code にバージョンアップ作業の詳細を聞いてみたところ、400行くらいの作業手順を教えてくれました。

どうやらソースコードの変更も必要なようです。当然、依存しているライブラリのバージョンも変えなければなりません。

しかし、初学者である私は作業の妥当性を判断できません。

結局この Lambda ってなにしてるの〜〜〜

今回バージョンアップが必要な Lambda は数年前に外部の方が作ったもので、我々のチームで継続的に修正・改善しているものではありませんでした。

S3にアップロードされた画像ファイルを圧縮・回転するための Lambda で、(おそらく)画像を扱うサービスであれば一般的な処理をしているのではないでしょうか。

しかし、内容を詳しく知らない私は作業によるデグレリスクを判断できません。

この戸惑い、これから先数年に一回やってくるのかな……

そんなこんなで何もわからない状態から作業を始めなければいけません。

無事終わらせる自信もなし、しかもバージョンアップって一回やったら終わりじゃないんだよなァと逡巡して、やっぱりテストを書くしかないな、と腹を括りました。

悩み始めて13分、テストを書く決意を固める

ここがすごいよ! メモリーチーム

ここまで気が重そうに見える文章を書いてしまいましたが、私はテストを書くのが好きです。

私たちのチームでもテストを書くことは当たり前で、チームのイケてるパイプラインでも常にテストが回っています。

Gaugeを使ったテストを書くのに慣れていますので、今回もGaugeを採用することにしました(その素晴らしさについてはまた別の機会に語りたいと思います。コドモンでのATDDの実践を紹介した記事もぜひご覧ください)。

やると決めたら、あとは簡単です。

テスト書いちゃおう!

いくら初学者とはいえ、Claude Code という歩行器があれば、現行の処理が何をしているのかは把握できます。

ある程度処理を理解したあとは、せっせとspecファイルを作るだけです。

書き出したテストケースの一例。全部で20ケースくらいになりました

今回は、バージョンアップ前後で動作が変わってはいけません。なので、実際の Lambda の処理後の画像ファイルを期待値として用意して、テストで Lambda を実行した後の画像が期待値ファイルと同一であるかをチェックすることにしました。

テストケースが洗い出せたら、その実装を Claude Code にお願いするだけです。 初学者ながら、ものの1日でテストを用意することができました。

技術の発展に感謝ですね。こんなに簡単にテストを作れるなら、やらない手はありません。

なぜテストを書くのか?

今回、十分なテストを用意できたことでバージョンアップ作業の心理的ハードルがかなり下がりました。

一回きりであれば、もしかしたら手動テストの方が早かったかもしれません。でも、自動テストはこれから先に発生するすべての変更のコストを下げてくれます。もしかしたら、この Lambda で写真に撮影日付を入れたくなる日がくるかもしれません。写真に保育者さんのひとことを入れたくなる日がくるかもしれません。そんなときに、画像の圧縮と回転ロジックが壊れていないか気にしなくてよくなります。

テストがあれば、どんな変更も怖くありません。何かを間違えたらテストが教えてくれます。ユーザーに届く価値を毀損していないか、リリース後に怯えながら夜を過ごす必要もありません。

チームメンバーの名言。勝手にタイトルとして拝借

幸運だったこと

Lambdaの処理がたいして複雑ではなかったのが幸いでした。もし数千行にも及ぶものだったら、こんなに簡単に作業を終えることはできなかったでしょう。

テストはプロダクトが小さいうちから書くに限ります。

でも、だからといって、プロダクトが大きく複雑になりきってからでは遅いということはありません。未来に比べたら、今が一番プロダクトは小さいのです。

私たちも、テストを与えられず大きく育ったプロダクトに、重要な機能からテストを作ってきました。おかげで、無限に挑戦できる状態になりつつあります(まだ有限かも)。

みなさまも、よきテストライフを!

余談

私が用意したテストは最初、Lambdaのhandler関数を直接呼び出す形でした。確かにPythonコードの動作担保はできていますが、Lambdaのランタイムのバージョンを上げても問題ないのかを厳密にテストできているわけではありません。

チーム内にPython × Lambda経験のあるメンバーがいて、今回のような場合はAWS SAM CLIの local invoke コマンドで Lambda を起動すると、より厳密なテストが可能だと教えてくれました。

また、別のメンバーは事前に本番環境のLambdaのアラートを設定してくれました。おかげでデプロイ後にハラハラしなくてよくなりました。(さらに、アラートを設定したことで恒常的にエラーが発生していることもわかってきました。改善ネタは尽きません。)

チーム開発だからこそ、盤石かつ迅速なバージョンアップができました! あらためてチーム開発のよさを噛み締めた年末になりました。