-
Notifications
You must be signed in to change notification settings - Fork 49
Readingagilesamuraiinchiba20120818
jupitris edited this page Sep 3, 2012
·
9 revisions
参加者は、自由に編集してください。
- 3名
- 第5部
- 実施範囲について、解釈を加える
- xUnitテストツールは、広く一般的に知られるようになってきた
- ただ、適用していないプロジェクトはまだまだ多そう(参加者の参画しているプロジェクトでは、適用していないケースもあるとのこと)
- ウォーターフォールを採用しているプロジェクトでは、使っていないことが多いのかも(あくまでも参加者の感覚的な統計からの推測)
- ユニットテスト
- リファクタリング
- テスト駆動開発(TDD)
- 継続的インテグレーション
- ただテストコードを書けばいいってもんじゃない
- テストする観点を考えて、もれなくテストすることが大切
ユニットテストすると、なにがいいの???
- 素早くフィードバックが得られる(当初想定の設計では実現できねんじゃね?とか)
- リグレッションテストにも使える
- デバッグ時間の短縮
- 自信を持ってデプロイできる
「小さな改修に、テストコードはいるのか?」
- いらないと思う理由
- テストコードを書く時間がもったいない
- 後続のテスト(IT、ST、QA)でリグレッションテストが可能であれば、ここでのテスト未実施は大目に見る
- 品質を保持し続けられる裏付けや確証があるなら(または品質に影響しないことがあらかじめわかっている)、あえてテストコードを書かなくてもいい
- めんどくさい・・・
- めんどくさがらずに書こう!
- 顧客がテストを望んでいない(納期だとか予算だとか不具合の軽視だとか理由は様々)
- 不具合が発生する可能性のあることを承知してもらいましょう
- ビジネス上の損失にかかわるであろう不具合が発生するかもしれないのであれば、そのことを説明しテストすることを認めてもらう
- テストコードを書く時間がもったいない