by shigemk2

当面は技術的なことしか書かない

アジャイルサムライ ユニットテスト:動くことがわかる

アジャイルなソフトウェアエンジニアリングのプラクティス

ユニットテストについて
プロダクトコードの振舞いが怪しいときや、期待通りに動くことを確かめたいときは、
いつでもユニットテストを書く。
テストコドをたくさん書くことのメリット

    • 素早いフィードバックが得られる
    • 極めて低コストにリグレッションテスト*2を実行出来る
    • デバッグ時間を大幅に削減できる
    • 自信を持ってデプロイできる

自動化されたテストコードを書くのが難しいときでも、部分的にでもいいからテストコードを書く
テストのないレガシーコードの危険性については以下の書籍を参考に。

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

  • 作者: マイケル・C・フェザーズ,ウルシステムズ株式会社,平澤章,越智典子,稲葉信之,田村友彦,小堀真義
  • 出版社/メーカー: 翔泳社
  • 発売日: 2009/07/14
  • メディア: 大型本
  • 購入: 45人 クリック: 673回
  • この商品を含むブログ (145件) を見る
ユニットテストの背後にある思いと考え方を理解したいなら下記リンクも参考に。
- テスト熱中症

まあ、テストを書くぶんコーディングの時間が2倍になるのでは?という疑問は生まれるが、
バグ修正の時間とかを考慮すると小さな犠牲ではある。

また、テストコードのカバレッジ(適用範囲)は100%である必要はなく、
カバレッジはチームで決めればよい。

*1:バグを修正するまえに、失敗するテストを書いてバグを再現してみる

*2:プロダクトコードを変更したときに、その変更によって既存のコードベースに予想外の影響が出ていないことを確認するテスト。回帰テストとも呼ばれる