「テスト駆動開発」を最近読んだので、その学んだことと感想を書いています。 shop.ohmsha.co.jp
なぜ読んだか
- ユニットテストで何をテストするか知りたい
- テストなので興味がある
学んだこと
TDDのサイクル
- テストを書く
- 動くコードを書く
- リファクタリングする
TDDのメリット
- TDDでテストを考えることで、きれいなコード、より良い設計の手助けになる
- 欠陥が少なくなる
- コードを信頼できる
- リリースの際に欠陥がでない
- 追加機能だけに焦点を当てれる
- ミスをしでかす確率が減っていることを実感でき、ストレスも減る
- 欠陥を見つけて修正する時間が少なくなる
- 開発を促進し、チームを支援する
テストについて
- テストは質を上げるのではなく、質を上げるのはプログラミング
- 質を上げるためにテストを書く
- テストでは質がわかるだけ
- TDDを厳密に行うとC0カバレッジは100%になる
- TDDのテスト＝Checking
- Testingではな意味
- テストの目的はコードに自信を持つこと→きれいなコードという意味だと認識している
その他
- 小さく進むこと
- 先にテストコードを書くことで、テストコードが仕様を守ってくれる安心感
- コードを修正してから、最後に「動け～」と念じながらテストをやらなくていい
- テスト間では独立している必要があり、依存関係は絶対に作ってはいけない
- 後続は正しいのに、前でエラーになると後続もエラー扱いとなってしまい、調査に時間がかかる
- １つの失敗は一つの問題であってほしい
- テストが独立していると、凝集度が高く低結合の設計にたどり着けれる
- テストメソッドは実行前の状態を完全に復元するように心がけなくてはならない
感想
テスト駆動開発と言うので、テストを先に書いて開発するんだろうな～と認識していました。もしかしたらテストに関する技法とかなりえるのかも？と思っていましたが、テスト駆動開発は設計手法である印象を受けました。
また、「テストでは質がわかるだけ」という点はすごく共感しました。これはTDDにおけるテスト以外も当てはまると思います。テストの役割/目的の一つはプロダクションコードの質を上げるための手段ということを改めて実感しました。特に、TDDにおいてはプロダクションコードを修正することでプロダクションコードの品質を上げる必要があるので、プロダクションコードの修正が無いならばTDDでは無さそうです。
テストコードを書ける時は積極的に書くことで、より良いプロダクションコードにしていきます！
