写経しながらテスト駆動開発を体験できる良書。
テスト実行→修正→テスト実行→修正→テスト実行→修正...のリズムを体で覚えることができる。
そのままSpringBootなどでTDDできるわけではないが、
TDDの核の部分は会得できるはず。
写経して追っていかないと、読むだけでは身につかないと思います。
TDDの概念的な話だけではなく、JUnitについても少量だが言及されているため、現場の指針にもなるでしょう。
テスト駆動開発のリズム
１ まずはテストを1つ書く
２ テストの失敗を確認する
３ 小さな変更を行う
４ 成功することを確認する
５ リファクタリングを行って重複を排除する
いきなりまずはテストを1つ書くことに驚きました。
テスト対象クラスを作ってではなく、まずテストクラス・テストメソッドを書きます。
その状態では当然テスト対象クラスがないので、コンパイルエラーなのですが、その状態でテストを失敗させることが「２」です。
「３」小さな変更を行うときは、まずテストを通すために文字列や数値はベタ書きの状態で実装を進めていき、テストが通ったら、徐々に変数に置き換えていくと言う方法がある（仮実装と言う）。
仮実装に対して、頭の中にコードが浮かんでいる場合は、いきなり変数などを実装していっても良い（明白な実装と言う）。
テストコードを先に書くということ
テストコードを先に書くということは、
ゴールを先に決めるということ。
テストコードがガイドラインになって、
あるべきコードの姿を教えてくれるという印象を受けた。
このことは、コーディングプロセンスが完全に逆転する。
TDDでなければ、先にコードを書いてみる、動作確認をして検証する。
TDDであれば、先にゴールを決めて、それに合わせてコードを書く。
という逆転になる。
TDDでなければ、コードが出来上がる。
TDDであれば、コードに加えてテストコードも出来上がる。
慣れたら、テストコードを書くのにそんなに時間はかからなくなるだろう。
早くテストコードを書くのに慣れてしまった方が良い。
良いテストコード
各テストケースは独立していなければならない。
@Test
class XxxTest {
public void testCase1() {}
public void testCase2() {}
public void testCase3() {}
}テストケース1の成否は、テストケース2~3の成否に何ら影響を及ぼすべきではない。
そうすることで、テストケースの実行順序に依存しなくなる。
独立したテストを心がけると、高凝集・低結合なクラス設計になっていく。
高凝集・低結合なクラス設計は、保守性が高い良い設計である。
テスト駆動開発に書いてないこと
この本は、「テスト駆動開発のなんたるか」は体験できますが、システム開発の現場ににどうやって取り入れるかは書かれていません。
・どんな目的で？
・どの工程で？
・どのモジュールに？
・どの粒度で？
そういうことは記載されていませんので、テックリードの人が自分のチームの品質担保のために自動テストを取り入れたいという場合は不向きです。
それらの点は訳者後書きで問題として指摘され、訳者なりの解説がありますが、体系的に説明されてるわけではありません。
ただし、1人のエンジニアがアサインされている案件に自動テストを根付かせたい、スキルアップのために自分の担当分だけでもちゃんと自動テストを書きたいという時の参考にはなります。
テスト駆動開発という言葉はエンジニア界隈では一般用語になっているので、その始祖であるケント・ベックの本書を読んだことがある、写経したことがあるというのは、長いエンジニア人生の中で大きな意味を持つでしょう。
↓↓↓今回レビューした書籍はこちら↓↓↓
