stubを作るのはいつ？

この記事はKyash Advent Calendar 2024 の18日目の記事です。

自己紹介

Kyashでサーバーサイドエンジニアをしてるtaniです。
社員ではなく、業務委託の契約で従事しています。

konifarさんに「書きませんか？」と言われたので、こういうのを書いた事はなかったのですが、お祭りに乗ってみようという事で「書きます」と回答して書く事になりました。

今回の内容について

今年開発を行った際に、新規に通信する先(他社)が増えました。その際に、動作確認用のstubを作るにあたり、いつやれば良かったかの個人的な感情をメインとして記していきます。

技術的な話というよりは、感情とタスクな話になるかと思います。

構成イメージ

通信先のシステムにAPIがいくつかあります。

開発の始まり

新たなサービスに向けて、夏頃開発がスタートしました。
通信先となるシステムも元々あるのではなく、同タイミングで新規に開発を行っていくことになりました。

今回の開発のサーバーサイドエンジニアは、自分含め4人の体制です。

やることとしては、モバイルアプリと新規の通信先システムをよしなにするのがメインになります。

開発中

開始

新規のシステムとなると、ひとまずIFの仕様がわからないとどうしようもないですね。
モバイルアプリの開発も同時に進んで行きますので、モバイルアプリ→サーバーのIFも決めなければいけません。
ここで、新規のIF仕様が出てきたタイミングで、対モバイルアプリのIFの仕様作成と新規システムとの通信の疎通を行いました。

こうしといたら良かったポイント1

このタイミングで、新規通信先のmockを作成すべきでした。
そうすれば、サーバーで用意するAPI単位での動作確認がスムーズでした。

ひたすら実装と疎通の繰り返し

リリースの目標があったのもあり、スケジュールは結構タイトに。
実装も急ピッチで行われて、単純な動作確認しかできず結合テストを行うことに。
案の定、新規の通信先となると、なかなか疎通がうまくいきませんでした。
ある程度はしょうがないとしてももう少しなんとかなっただろうなと思う日々でした。
しかし、結合テストでのバグ対応は大変だったなぁ。

こうしといたら良かったポイント2

このタイミングでstubを並列で実装し、機能テストを行えてれば、スムーズだったなと。ここで思ったのは、新規の所なので、新規の通信先との結合テストを行う前にしっかり機能テストができていればスムーズだったなと思いました。

開発完了

沢山の人が頑張って無事サービスインしました。
サービスイン後、ちょっと時間が取れそうとのことで後追いでstubを実装することに。

stub実装

実装開始

stubを作るにあたり、最初に考えたのは後から見た人が手軽に手を入れられる様にすることを意識しました。
自分がいつまでいるかもわからないし、ツールに対して理解に時間がかからないようにし、誰でも修正できる状態を目指しました。

まずは、社内のドキュメントにstubの大まかな修正履歴とプルリクのリンクを記載することに。調べる時に当時のプルリクを探すのって意外と手間だったりするので。

以下の感じで実装を行いました。
stubへの切り替えと固定値を返却(mock実装)
状態管理とその状態でのレスポンスを返却する実装
状態を変更する機能の追加
その他、優先度の低かった機能の拡充

実装中

コツコツと作っては動作確認をし、自分ではそれなりのものができたと思ってます。
実装中よかったのは、ちゃんとアプリから動作確認を行ったので、画面の遷移でおかしい所を見つけたり、仕様をより深く理解できました。
先にやっとけば、その時詳しくなれたからバグもっと減っただろうなぁと思ったりもしましたが。

実装後

機能修正を行いテスト実施の際に、通信先に状態更新の依頼を行わないとテスト出来なかったものが、社内で解決できる様になり、テストのスピードは上がったのではと思っています。
特に、ちょっとした画面変更や通信先に影響のない修正を行った際に、テストの度に先方へ依頼した時の待ち時間を考えるとかなり改善されました。

最後に

stubはとっと作った方が良かったです。
新規の通信先のIFがFIXされた時点で、固定のレスポンスを返すmockを実装し、テストが始まるタイミングで、一連の動作確認ができるstubを実装するのがベストだったなと思いました。
これやれていたら、テストの工数もだいぶ減っただろうなと思います。
実際にstubの運用が始まってから、機能テストはすんなり実施できています。

今、振り返っても当時はなかなかハードでしたが、目先だけではなく、先を見据えてタスクの優先度をつけられれば良かったなと思いました。