はじめに
この記事はInsurtechラボのアドベントカレンダー28日の記事です。
私たちのチームは、1月からの3か月間TDDでコーディングを行っています。実際にTDDを行ってみたので、振り返ってまとめました。
TDDをはじめた理由
ラボ内では品質の高いシステムを開発できるケイパビリティを取得するために様々なアプローチを実施しています。
システムの品質を高めるための様々なアプローチがある中で、メンバーが興味を持っていたTDDに取り組んでみることにしました。
我々はTDDをどう進めたか
環境
- Next.js v14
- vitest
経験
TDD経験者なし
インプット
インターネットで各自情報収集をして、共有を行った。
動作するきれいなコード: SeleniumConf Tokyo 2019 基調講演文字起こし+α
https://t-wada.hatenablog.jp/?page=1586393100
TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング
https://www.youtube.com/watch?v=Q-FJ3XmFlT8
フロントエンド（React Testing Library）で TDD（テスト駆動開発）をする
https://zenn.dev/higa/articles/34439dc279c55dd2ab95
振り返り
戸惑ったこと
リファクタリング前提で開発するということ
TDDではまず「動作するコード」を書いて、その後リファクタリングによって「動作する綺麗なコード」に改修していくような進め方をするが、これまでの開発では「綺麗でないコード」の状態のまま次のステップに進むことは無かったので抵抗があった。
リファクタリングのレベル感を合わせること
リファクタリングをいつするか？どこまでするか？は好みやバックログの優先度など色々な要素が関係するため、チーム内で認識を合わせるのが難しかった。
テストコードよりも先に実装してしまうこと
例えば条件式でtrueの場合のテストコードを記述して実装に入ったとき、falseの場合の処理まで勢い余って実装してしまい、その後falseの場合のテストコードを作成したときに、最初からGreenになるようなことがあった。
テストの順番や実装粒度をしっかり見極めないとRed→Greenができない。
テストコードを想定結果から書いていくこと
TDDではまず最初に期待値（assertEquals(expected, actual) など）を記述してから、上に上がっていく感じでテストコードを書いていきます。
これまでは上からコードを書くことが当たり前だったため、TDDで下からコードを書くことになれるまで時間がかかった。
つまづいたこと
テストケースを一覧することが難しく、テストコードが動くドキュメントにならなかったこと
テストコード自体が長くなり、テストは全てgreenだが、ToDoリストにどんな項目が存在するか、ToDoリストが全て網羅されているか、が分からない状態だった。
リファクタをめんどくさく感じてしまったこと
プロダクトコードのリファクタはある程度筋の通った方向性でリファクタの要否を決めていたが、テストコードのリファクタは量が多く、実施を躊躇ってしまった。
プロダクトの将来的にあるべき姿が気になり、作業の手が止まったこと
汚く最小限に実装しようと思っても、将来的に拡張しやすいようにしたくなった。
やってみて感じたTDDのメリット
テストコードが必ず作成される
テストがない現場もあるらしく、テストコードが必ず作成されることはメリットだと感じた。
- 仕様書のような存在（テストコード）が結果としてできる
- 今回は綺麗化できなかったが、テストコード（またはToDoリスト）を見れば、対象のモジュールにどんな責務があるのかわかるようになるはず、であることは感じた
- 設計に近いことができる
- テストコードを記載している中で、プログラムの修正箇所や修正方法のイメージアップができるため、プログラムの修正はスムーズに感じた
- テストを書く経験が得られる
- 何をどう確認できればよいか？を考える経験が自動的に積める
大きな実装タスクを細かく分割できる!
今回はテストケースの粒度が大きかったものの、それでもタスクの分解が自動的にTDDプロセスの中で行われたため、タスク粒度の細分化に役立った
リファクタリングや綺麗化が今必要か?を考えることができるようになる
「完璧主義の呪い」から解放される。常に実装・リファクタの優先度を考えながら開発できる（これは間違った解釈かも。リファクタってスキップしちゃダメ？）
やってみて感じたTDDのデメリット
実装が進むスピードが遅くなる
テストコードを書く→実装の手順を毎回踏むのでひたすら実装するより遅くなる。
めんどくさがりに「汚く済ませる」理由を与えてしまう
まずは汚くて良いという免罪符を与えてしまうのは問題な気もする
まとめ
良い
タスク粒度を分解できたり、テストコードが作られたり、良いことづくしな気がする。リファクタには勇気と根気が必要なので、そこだけどうするか考えたい。
慣れって大事
良い点はいろいろあるが慣れが必要な部分が多々あるため、慣れるまでTDDできれいに作るのは難しい気がする。
