- - PR -
ユニットテストやってますか？
| 投稿者 | 投稿内容 |
|---|---|
|
投稿日時: 2006-02-09 00:15
最近、転職してきたのですが、上司（ＰＭ経験者）と開発方法論について
話していて、ちょっと驚いたことがあります。 「ユニットテストが有効ですよ」という話をしたら、「そんなものでバグが 全部出せるわけない。何でもかんでも新しい方法に飛びつけばいい、という ものではない」と一蹴されてしまったのです。 前の職場では、ユニットテストは非常に有効だったので、ちょっとびっくり でした。 確かに、ユニットテストはテストを書くコストが意外にかかるため、 導入できないケースもあるとは思うのですが、有効性を完全否定されたのは 初めてだったので、ちょっとしたカルチャーショックでした。 みなさん、ユニットテストやってますか？ |
|
投稿日時: 2006-02-09 06:51
どうやってシステムの品質を確保してるんでしょうね？？
でもUnitテストを書くと，すごい時間とってしまうのは事実ですね。 （テストはしなきゃいけないから本来は，その時間もちゃんと含めて 見積もりしないといけないんですけどね） |
|
投稿日時: 2006-02-09 10:23
上司といっても、直接の仕事には関係ないので、どうやって品質を確保
しているのか、詳細は不明ですが。ちらりと見たところ、昔ながらの マトリックス表とかでやっているみたいです。 仮に、画面上にA と B の２つの項目があったとして、それぞれ10種類の値が 入力する可能性があり、その組み合わせによって次画面の表示内容が異なる としたら、100パターンのテストをしなければいけないわけです。 こういうのを手でやっているようです。 |
|
投稿日時: 2006-02-09 11:35
ユニットテストを第一義のメリットはテスト工数の削減だと思うんですよ。
コーディングの初期の段階から出荷直前まで、テストは何十回も何百回も繰り返されるはずです。１００件目のテストケースでバグが出たら、再び１００件のテストが必要になるのです。これを手動で行っていたら、テスト工数がいくらあっても足りませんよね。 品質の改善はテスト工数の削減により、二次的に生まれるものだと持っています。テスト工数が削減された事によりテストケースを増やしたり、コード修正のリスクが小さくなったり、コードのレビューを時間を作れたり、出来るわけです。 ＃バグを全て検出する方法があるなら、是非教えて欲しいものです。 ＃そんな方法が無いから、みんな次善の策を探していると言うのに。 |
|
投稿日時: 2006-02-09 21:01
100件めでバグが出たら、たぶん、100件めのケースだけテストするのだと思います。
10x10パターンが、10x11パターンになったら、増えた分だけやるのでしょう。 どうも、テストは開発の終盤にだーっとまとめてやるものだという、固定概念がある ようです。 その人が書いたソース（Java）を見たら、オブジェクト指向どころか、MVCモデルも 満足にできてないし、クラス同士が依存しまくりで、こりゃユニットテスト 書けないな、と納得してしまいました。 |
|
投稿日時: 2006-02-09 22:20
マジメにユニットテストのコードを書くとテストコードのほうが何倍も規模がでかくなるから，ちょっと大変。
ユニットテストを前提にかかれてないコードを無理矢理ユニットテスト書くのは，しんどいのでその人は嫌ってるんですかね？ |
|
投稿日時: 2006-02-10 09:33
というより、「テストをコーディングする」「テストを何十回も行う」という考えを
拒否しているのだと思います。 たぶん上司の頭の中では、「最初にしっかり分析しておけば、バグは少なくなる」 「途中でコードを大幅に変更するのは設計が悪い証拠」という概念があるのでは ないかと。 自分は逆で「完全な分析は無理」「設計は開発途中でも頻繁に変更する」という概念が あるので、ユニットテストの重要性と利点がわかるのですが。 以前、Ｈ系の技術者と仕事をしたときも、同じような固定概念に悩まされたことが ありました。 |
|
投稿日時: 2006-02-10 10:03
長距離走の走り方で、短距離を走れば遅い様に、
短距離走の走り方で、長距離を走れば息切れします。 状況によってそれぞれ取るべき「手段」が異なるのは当然だとおもいます。 基本的な理想は上司さんのおっしゃる通りとおもいます。 しかし、時流というか最近の開発傾向（短納期等）とはあわない場合や、 物事「理想」通りにはすすまない事の方が多いので、みなさんいろいろと 工夫されているわけです。 ある意味その「理想」が実現できている「力（ちから）」があるのであれば、 それはそれで、すばらしい事です。 そんな環境にいるのですから、ぜひ相手からどのようにテストを行なって いるのかを詳しく聞いてみるのはどうでしょう。 せっかく同じ会社にいるのですから、「思う」ではなくて実際に行なっている 現場の人に聞いてみた方がいいですよ？ # もしかすると、現場では別の方法でテストしてるの、かも。 あと、直接の仕事に関係しない（相手の手法に強制されない）のであれば、 自分の思う通りに進んでいけば良いと思います。 上司さんと flatline さんのそれぞれが行なっている仕事において、 バグの発生件数等の情報を調べてみると面白いかもしれませんね。 |
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。