書籍の感想「テスト駆動開発」
以前、私が参加しているJavaのサロン(で合ってる？)JPINにて読書会があり、そこで感想を共有したのですが、業務を通じて自分の中で改めて持った感想をここにまとめようと思います。
まず、やってみよう
読み終えた最初の感想は、自分一人でもやってみたいし、ある程度テストが書ける人が相手であれば、ポイントを押さえた説明をすれば曲がりなりにも複数人で実践できそうな気がすると感じました。 読み終えたタイミングで、派遣先プロジェクトのリーダーさんにTDDを読んだうえでやってみる旨を話したところ、ぜひぜひということですぐに取り掛かれました。 そして、他のメンバーにもなるべく具体的になるよう作業説明をして実践していただきつつ、自分でもやってみました。
実際に作ってみると、書いた実装を読み解きながらテストを書くよりもスムーズかつ、漏れが起きないように感じました。 スムーズというのは、「処理としてはザルなんだけどとりあえず期待値を返す」状態から、動いてほしい処理のwhenやverify(JavaなのでMockitoを使っています)を書いてから実装に反映させるので、無駄なモックを作らない感じがしました。 漏れが起きないというのも、テスト対象が依存している処理の呼び出し有無判定が抜けないので、より正確に書けていると感じました。
利用しているクラスのテストはどうする？
ちょっと悩んだのはこの書籍のやり方だと、今まで自分がテストを書く際にやっていた、テスト対象ソースとテストソースが1対1になる、対になる状態にはならないことが気になりました。 ただ、テスト駆動であるおかげで必要な処理バリエーションはきちんと確認できているので問題はないはずなんですよね。 この後感想を書くつもりである『良いコード／悪いコードで学ぶ設計入門―保守しやすい 成長し続けるコードの書き方』も踏まえてテストを書いていくと、DTO(※的なものとしておきます)はただのGetter/Setterだけを持つクラスにはならずに判定処理やデータ加工のメソッドを持つようになったんです。 そして、このクラスに対してのJUnitテストソースが必要かなと思ったのですが、DTOの利用クラス側のテストで十分にパターンは網羅できたので、その結果としてテストソースの量が減るならば喜んでよいのではないかなと思うのです。 この辺はTDDの書籍を読んだことのある人が管理者側にいるか、自分がつよつよエンジニアになれば納得してもらえるようになるのかなあ、とぼんやり思いました。
ウォーターフォールにも合う
TDDって、正直アジャイル的な手法だと思っていました。 ですが、これはウォーターフォールにも適用可能な手法なんだと実際に試して理解することができました。 結局単体テストで動作を定義しながら実装を作っていくのって、デバッガを使用したり、ローカルでアプリそのものを起動して動作確認しながら実装していくのと変わらないと感じたんです。 それに、
- 実装期間中に単体テストも着手できる
- テストソースを書いているため、自分の実装した処理による結果が明確にされている
- 手戻りがあっても、『テストを正しい方に変更→実装を変更』の流れで柔軟に対応できる
ということで、実装を終えてから単体テストソースを書くよりも良いことが多かったです。 「テストを書きながら実装をするんだから、工数的には多くなるじゃないか、余計に時間がかかるのではないか」という印象もあったのですが、ありませんでした。 前述した『デバッガを使用したり、ローカルでアプリそのものを起動して動作確認』の時間がテストソース作成の時間に置き換わるだけでした。
また、テストをすでに書いているので、処理をメソッドや別クラスに切り出すといったリファクタリングにも対応できるのが嬉しいポイントでした。
結論「TDD、怖くない」
テストを書いて動作を定義しながらの実装は良いことずくめでした。 最高。
