極力とは？/ マイワン
[ 537] 極力ユニットテストを書かずに品質を確保する方法 - ひがやすを blog
[引用サイト] http://d.hatena.ne.jp/higayasuo/20080423/1208922541
|
今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 これまでは、「ユニットテストは、できるだけ書いたほうがいい」というのが一般的な見解でした(と思う)。でも、「そういわれても、ユニットテスト書くのも工数がかかるし」という人が多くて、ユニットテストが普及していないのも事実です。そういう人たちに対して、「ユニットテストを書いたほうが最終的にはコストが下がるんだ」と説明しても、あまり納得感はないでしょう。事実、ここ数年、「ユニットテストは工数がかかる」と思っている人と「ユニットテストを書いたほうが最終的にはコストが下がる」と思っている人の会話は平行線のままです。 また、最初にユーザに実際に動かしてもらっているので、開発者が、仕様を勘違いするという「仕様バグ」をほとんどなくすことができます。修正が大変なのは、「仕様バグ」です。実装バグは、後から見つかっても、直ぐに修正することができるでしょう。 2008/04/23 23:32 ユニットテストを書こうと書くまいとテストをもれなくこなせば品質は確保できると思う。また、ユニットテストはレグレッションの時に効果的だけども、プログラム設計を影響度がないような疎結合の集合体にすることでテストを搾ってできるのでそれだとレグレッション回数も減る。１，２回のレグレッションで終わるようならユニットテストいらないかも。あと、ソースだと保存、保管コストが増えるとこ。そういえば、ユニットテストが本当に正しいかどうかってところもついてきた上司がいたな。ユニットテストのテストが必要だろうみたいなｗ 2008/04/26 13:08 「仕様は変わるもの」という前提でユニットテストのメンテナンスに工数がかかるという人と、「綺麗なソースを維持する」ためにはユニットテストが足りないとリファクタリングし難い＆品質を担保できない、と主張する自分の間でまさに平行線でしたw本質的にはどうあるべきなんでしょうね・・・ |
マイワンのサイトです。
