まとめ
いきなりですが、私がTDDを実施するために必要だと感じたこと(今回足りなかったこと)
1. 詳細設計所(もしくは十分な業務知識の理解。何を作ってるのか?)
2. 単体テストをするための準備(繰り返し実行しても同じ結果が返ること。DB定義の更新があった場合取り込めて、データの作成の手間が最小になるような環境に出来るのが理想。どうやるのがベストなのか、まだわかりません)
3. 体制準備(テストがオールグリーンじゃないとpushできないくらいの強制力のある仕組みを用意してもいいかも)
4.pullrequestの単位を小さくすること(単位がでかすぎると結局どういうコードがあって、どんなテストがされてるのかわからない。初めにテストを書かせて、どんなテストをするかレビューした後にコード実装に入ってもいいかも)
なぜTDD?
- 既存のソースコード改修してリリース->予想外の場所でエラーが･･･
- メソッドが長すぎて何やってんのかよくわからん
- とりあえず実装したけどバグがやばい！
↓
こんなときにTDDで開発すればきれいさっぱり解決します！
(今回私は完全に達成できなかったのですが、体感として一部あります。)
メリットデメリット(書籍の内容&私が感じたこと)
| メリット | デメリット |
|---|---|
| 1. メソッドが最小になりやすい。 2.既存のコード改修時に既存の振る舞いに変更がないことを確認しやすい。 3.業務ロジックがわかる(テストを記述するためにはどういうテストが必要か?を知る必要があり、最低限の業務を理解している必要がある) 4.リファクタリングが容易 |
1.コード量が倍になる 2.テストを書きなれていないと時間がかかる(個人差あると思います。) 3.それなりに技術力が必要(どんなテストがあるのか?) 4.既存コードへの適用は大変 |
当たり前かもしれませんが、テストを書いて、ちゃんとグリーンで通ってるよねってことが確認できてもそれが必ずしも業務要件や、パフォーマンス、ユーザビリティを保証しているものではないので、そこは別途注意が必要だと思います。
失敗したこと(こうなって欲しくないこと)
- ソースレビュー時にテスト長すぎてバーがグリーンになるけど結局何やってるかわからない
- 単体テストがかけるレベルの詳細設計所を書けなかった。ざっくりとした要件で伝えてしまったので、テストは全てグリーンになっていたが、業務要件が満たせていなかった。
- 単体テストをする環境作り。個人の環境で何回実行しても同一のテストが繰り返しグリーンになるようなDBおよびテストデータ作りの十分な知見がなく、それをするための環境の整備ができなかった。
- プロジェクトが炎上したときにテストコードを最後まで書ききることができない部分があった。