2019卒で入社した、Holmesの倉島です。(サーバーサイドエンジニア)
2020年の1月から、自社でTDD(テスト駆動開発)を推進していく方向になりました。
そこで、私が開拓を任されましたので、ブログ記述時現在(2020年4月)まで約３ヶ月間TDDを行なった感想を述べたいと思います。
TDD開始時点
エンジニアとしての経験が浅いので、まずTDDとは何者かを知るところから始めました。
参考にさせていただいた資料:
理解したこととしては...
・テストコードを記述してから実装をすること
・RED→GREEN→リファクタリング の3つのサイクルに沿って開発を行うこと
RED:落ちるテストを記述
GREEN:とにかくテストが落ちない実装をする
リファクタリング:テストが落ちない状態を維持して、意味のある実装にする
以上を意識して開発を行なってみました。
結果的に、プロダクトのカバレッジが15%上昇しました！
以下は行ってみての感想です。
よかったこと
1.テストコードを記述しない、という事が減った
テストコードを後に回してしまうと、記述し忘れや、時間の問題でテストコードが記述されないままになってしまう事がありました。TDDであればテストコードを記述してから実装を行うので、記述しないということは無くなっていきました。
2.仕様の確認をしながら実装することができる。
テストコードを記述するにあたって考えなくてはならない事が、「処理を通して如何なる結果を期待するか」であるので、何をしたいかが明確になる。私は「何から作ればいいんだ？」と思う事が多々あるので非常に有効でした。
3.画面(フロント)が完成する前に、サーバー側の動きをチェックできる
画面上から動かす事ができなくとも、処理の動きは確認する事ができるので、フロント側とサーバー側に作業のズレがあったとしても一定の処理の保証ができることが大きなメリットだと感じました。
4.既存処理の改修(リファクタリング)、仕様変更が楽。
テストコードが記述されていると、その処理は何をする処理なのかが理解しやすいし、既存のテストが落ちないようにリファクタリングをすれば良いので、悩む時間が(体感)減ったと感じました。
よくなかったこと
1.セットアップコードが多い場合やデータ関連が複雑な場合は時間がかかる
処理を動かすためのデータを用意する時間がとても多くなって、時間対効果が見込めなくなることがありました。
2.処理の結果が不鮮明な場合のテストコードが雑になりがち
処理の結果が不鮮明であると、テストで期待する結果が書きづらかった。例として、受け取ったデータを別の処理に送るだけの処理が挙げられます。結局、そういった処理は期待する結果を「エラーが出ない事」のみにしてしまうケースがありました。
3.テストの起動がすこぶる遅いので、時間がかかる(環境依存)
Holmesの開発環境に限った話ではあると思いますが、 Spring Boot を使用して起動を行なっていることに加え、DIコンテナで管理しているクラスの量が多いのでテストの起動がとても遅いです。一回の起動に2分ほどかかることもありました。
まとめ
TDDを行う上で最も気を使ったことは、どこまで端折りができるかだと思います。というのも、TDDのサイクルは細かくしようと思えばどこまでも細かい単位で行えてしまいます。この部分のこのテストは不要、と適切に判断し不要なテストを削っていくことがTDDにおいて大切なことだと感じました。 TDDを行なって、享受できるメリットは多いと思います。個人的には仕様の確認をしながら実装ができることが大きなメリットだと思いました。 また、上述の「2.処理の結果が不鮮明な場合のテストコードが雑になりがち」のようにどんな場面でも効果を発揮するものではないことがわかりました。
終わりに
私の感想が、TDD理解、導入への一助になれば幸いです。
Holmesはエンジニア・デザイナーを募集しています 。
興味がある方はこちらからご連絡ください！
