0から作ったプロダクトに、いつ自動テスト入れるかの話
ミチビク株式会社取締役CTOの金杉です。
取締役会DXのミチビクを運営しています。
今回CTO協会のアドベントカレンダーの19日目を担当させていただけることになりました。
Qiita x 日本CTO協会共催！あなたの自己変革について語ろう！ Advent Calendar 2022
「Give First / あなたの当たり前は誰かの学び」をテーマに
「0から作ったプロダクトに、いつ自動テスト入れるか」について書きます
0から作ったプロダクトに、いつ自動テスト入れるか
ミチビクという取締役会のDXツールの開発しています。
今はまだ小さいスタートアップですが、
将来は、日本のすべての企業に導入してほしい。
取締役会のDXのためには、ミチビクが必要だと信じて開発をしています。
そのための第一歩として、継続的に機能を早く開発し続ける必要があります。
創業者CTOの悩みの1つとして、自動テストをいつプロダクトに導入すべきかという難しい意思決定があると思います。
これはジレンマで、早くから入れれば、質があがるが、開発速度が遅くなる。
自動テストを入れるのが遅いと、初速の開発速度があがるが、質の維持が難しく、どんどん開発速度が遅くなっていく。
いつ自動テストを入れればいいのか？という問いに対して、
こうすればいいという唯一の答えはありません。
自分たちも、どのタイミングでどのような自動テストツールを取り入れればいいのか、試行錯誤しながら進めていきました。
ベストプラクティスという訳ではないかもしれないですが、
自分たちはこうやったという一例を共有できればと思い、筆を執らせていただきました。
技術スタック前提
- Next.js
- Node.js
- Prisma
- TypeScript
フェーズ
フェーズとしては、以下の6つに大きく分けて記載していきます。
- 創業時
- 仮説検証
- ベータリリース
- 本リリース
- PSF(Problem Solution Fit)
- PMF(Problem Marcket Fit)
1. 創業時
どのようなテストツールを使うかの選定をしました。
まだプロダクトが実際にどうなるのかなどの検討はまだ確定していなかったのですが、すでに自動テスト系のライブラリの選定はしていました。
プロダクトの初期段階で導入しておかないと、後から導入するのは非常に大変だからです。
あとから自動テストを入れるということは、新規機能の開発を止めてしまったり、スピードを遅くさせてしまい、
社内外への説明コストが非常に高いので、この段階ですでに検討していることをおすすめします。
2. 仮説検証
figmaのモックをつかったりして、今作ろうとしているプロダクトにニーズがあるのかの検証と同時に、ログインなど基盤となる部分のコーディングを開発を進めていたフェーズです。
具体的には、以下を導入しました。
- Storybookの導入
- eslintなど静的解析系の導入
- Jestの基盤の導入
仮説検証の結果によって、プロダクトの方向性が変わる可能性があるので、仮説検証の結果に依存しない部分の基盤を作っていました。
今振り返ると、eslintなどはこのタイミングで入れるのはけっこう普通な感覚ですが、
ちゃんと、Storybookまで入れることができたのは、後から振り返ってみると良いポイントだと思いました。
3. ベータリリース
プロダクトの仮説検証が終わって、作りたいものが決まり、一気にプロダクトを作り上げました。
この時は、当たり前ですが、スピード重視の実装になります。
しかし、中長期の負債にならないように気をつけながら実装していきました。
- Jestのカバレッジが20%
- CI上で、静的解析とJestが回る状態
2-3人で開発をしていたので、スモールチームで開発をしていました。
この時のJestのカバレッジは、20%程度で、本当に大事なところだけ適宜判断してJestを書いていました。
また、CI上でPull Requestをremoteにpushすると、Github ActionsでCIでeslintとJestが自動で流れる仕組みを構築していました。
反省としては、CIの仕組みを入れるタイミングはもしかしたら、もう少し後でもよかったかもしれないということです。
2-3人で開発をしていて、まだ圧倒的にスピード重視で実装していたので、そこまでCIが役に立ったみたいな実感もなかったからです。
4. 本リリース
以前として、スピード重視な開発体制ですが、人数も少し増えてようやく落ち着いてきたようなフェーズです。
ベータリリースから、本リリースまでは複数回、マイナーバージョンのアップデートをしていたので、デグレなどを徐々に気にするようになってきました。
この頃から、継続的にチームで質を高いコードを素早く書くために、自動テストを強く意識しだしたと思います。
ただ、意識しだしたころに、自動テストを導入したのでは、すべて後手に回ってしまうので、この頃までに自動テストの基盤がある程度構築されていて、
かつ、CI上でも回るような状態。
新しく入ってきたメンバーも既存のテストコードを真似しながら書けば、どんどんテストコードも増やせる状態にしておいたのは良かったなという所感です。
-
e2eテストの導入
-
Jestのカバレッジが50%
-
CI上で、静的解析とJestと、e2eが回る状態
e2eも導入をして、正常系のテストを自働でPull Requestのたび流すようにして、デグレをできるだけ早いタイミングで検知するようにしました。
5. PSF(Problem Solution Fit)
プロダクトをつくっていて、「お、これってユーザーに刺さっているのでは？」と少し実感が見えるフェーズです。
弊社の執筆時の状況としては、今このフェーズにいるのではないかと分析しています。
この頃には、チーム開発も軌道に乗っていて、安定的にリリースできている状況です。
したがって、少しリファクタや、開発改善系のタスクの余裕も生まれ、Jestのテストコードもどんどんカバレッジが高まるように書いていきました。
- Jestのカバレッジが80%
- CI上で、静的解析とJestと、e2eが回る状態
- dependabotで自働でライブラリ更新に対して、CIが回る状態
- StorybookがPull Request常にホスティングされている状態
ある程度、自動テストも書き切ったりしたので、自動でライブラリが更新できるためにCIを回したりもできるようになりました。
StorybookもPull Request毎にホスティングするようにもして、コンポーネントのテストにも力を入れ始めたところです。
6. PMF(Problem Marcket Fit)
弊社はまだPMFまでたどり着いたとは言えない状況ですが、この状況も見据えて、色々準備を進めています。
- e2eでのテストケースの増強
- スナップショットテストの追加
- coverage計測ツールの導入
ここまでくれば、開発チームとしては、普通のチームといいますか、一般的な開発チームと同じような状況になっているのではないかと想像しています。
スタートアップの創業時のあれこれは徐々になくなっていて、いろんなバックグランドのメンバーが入り、
継続的に不具合修正や機能追加をどうやって、安定的に素早くしていくのか？といった課題がでてくるころのはずです。
その課題に応じたQA戦略が必要になるので、そのための対応を一定工数を確保して対応していきます。
まとめ
振り返ってみると、必要なことは半歩先を見通した自動テストの戦略が必要だということです。
必要になったタイミングでは導入されていないといけないので、いつ必要になりそうかを
プロダクトの様子を見ながら、チームの状況をみながら、リリースの状況を見ながら、判断していく必要があります。
Discussion