正式な単体テストの有用性に関する指標を持っている人はいますか? 単体テスト ツールに多くの注意が払われているのを目にしますが、その理由を知りたいと思いました。
私は 5、6 年以上前に正式な単体テストをやめましたが、生産性の純利益はかなり高いようです。ユニットテストをやめたのは、何もキャッチされないことに気付いたからです。単体テストで検出されるエラーのタイプは、ワイン/ビールを 1 時間あたり 2 杯 (または 1 時間あたり 2 杯) 以上飲まないことで防ぐことができるようです。また、単体テストは、開発者が自分の間違いを発見するための安全策があると考えることを可能にするため、リスクを生み出すようです。
コードが正常に機能することを確認するためにテストを行いますが、ツールは使用しません。加えられた変更に基づいてテストします。新しいコードの生産エラー率はほぼゼロです。コードの変更に関する私のエラー率は、四半期ごとに約 2 ～ 3 個のバグです。上記の対策は、私が開発/サポートしている 4 つの製品アプリケーションに基づいています。
私はあなたが人間として、またコーダーとして優れていることを認めます。
しかし、私はただのバカで、Python 単体テストがなければ道に迷ってしまいます。
単体テストなしではリファクタリングできません。考えすぎるだけです。
単体テストなしではほとんどコーディングできません。すべてのニュアンスを完全に理解していることを完全に確認するのは難しすぎます。
私はばかなので、単体テストを行います。間違いを犯さないので、明らかに単体テストを行う必要はありません。よろしくお願いします。
編集。私にとって、単体テストはメトリクスやコストに関するものではありません。値を示すために、無作為に制御された実験は必要ありません。彼らなしでは仕事ができません。確かに、私はそれらなしで働くことを拒否します. 同様に、コンパイラ、テキスト エディタ、またはソース コード管理がなければ作業できません。私は要件なしでは働きません。最初に設計を行わずにプログラミングすることを拒否します。
私は単体テストを従来のテストに代わるものとは考えていませんが、コードの正確性を保証するための追加のステップと考えています。単体テストが役立つと思う特定の分野は次のとおりです。
おそらく私が忘れてしまった他のいくつかのこと:-P
PS: バグを作っていないとどうしてわかるのですか? 私は自分が取り組んでいるコードにバグを持ち込むとは思いませんが、だからといってそうなるわけではありません。IMHO、あなたのコードにバグがないと考えるのは単純です。
(単体テストに関して、コードにバグが含まれている可能性があることがわかっている場合、ほとんどのコードにはバグが含まれていると思いますが、それらをキャッチするためにあらゆる手段を使用したいと思いませんか?)
以下は、ユニット テストに関するホワイト ペーパーです。
しかし、Martin Fowlerは、単体テストと TDD を裏付ける事例証拠は圧倒的ですが、生産性を測定することはできない、と述べています。
単体テストは、パーツを変更して、他の場所で何かが変更されたかどうかを知ることができるため、優れています。一部の人々は単体テストに「恋をしている」ので、落ち着く必要があります。私は単体テストを信じていますが、すべてを隠蔽しようとする人々は、単体テストを行わない人々と同じくらい危険です。
指摘する指標はありませんが、人気が高まっているのは、私たちの残りの人があなたとは反対の経験をしたからだと思います. :)
これは、TDD アプローチに関する研究を行っているスレッドです。 TDD に関する 研究
私は開発マネージャーです。私の組織では、nhibernateのセットアップと移行にはセットアップコストがかかり、開発時間も長くなりました。開発者の中にはそれが好きな人もいれば、時間の無駄だと思った人もいました。
エラー率に目立った変化はありませんが、おそらくそれを伝えるには時期尚早です。
私の見解では、それは自分の仕事に自信がないジュニア開発者には役立つと思いますが、シニア開発者にとっては、彼らを遅くしているように見えます-それは更新を続けるもう1つのことです。これを使い続けるのか、以前の方法（アドホックユニットテスト）に戻すのか、開発者に個人的な選択をさせるのかはわかりません。
単体テストを使用すると、実稼働コードのバグを修正し、バグが見つかった 1 時間以内に新しいバージョンをインストールできます。また、新しいバージョンが以前のものよりも悪くないことを確認できます。でも、そのほうがいいかもしれません。
それらは、私のコードの品質が決して沈むことのない、より低いウォーターマークを私に与えてくれます。これにより、全体像を把握し、私が犯しがちな小さな間違いをテストで見つけることができます。また、非常にリラックスしたスタイルで成長することもできます。
私はテストを行っているため、納期どおりに納品する傾向があり、コードの品質は大幅に向上し、結果は通常期待どおりに機能します。また、テストを受けていなければ危険すぎて試すことができないコーナーをカットできるため、はるかに高速です。
そうは言っても、何年も単体テストとTDDを行っているという事実にもかかわらず、私は具体的な数値も持っていませんし、ソースも知りません。テストに対する私の愛情は、純粋な口コミと個人的な経験に基づいています。
新しい機能を追加するときに、単体テストが役立つことがわかりました。このシナリオでは、追加したものがアプリケーションのリモート部分で何かを壊すのではないかと心配していました。しかし、適切な単体テストがあれば、テストを実行した瞬間に何かを壊したかどうかがわかります。
単体テストの有用性に関する興味深い議論があります。
単体テストが気に入らない場合は、検討したい別の概念としてDesign By Contract があります。 基本的に、特定の入力条件が満たされている場合、契約に従って出力が保証されると主張しています。
私は特に、巨大なモノリシックサーバーアプリケーションでC ++を使用したテスト駆動開発（TDD）を使用することで多くの利益を得ました。
コードの領域で作業しているときは、新しいコードを変更または作成する前に、まずその領域がテストでカバーされていることを確認します。
このユースケースでは、生産性が大幅に向上します。
これは、コードの領域を非常に迅速に反復し、必要な場合にのみ完全にテストできることを意味します。
これに加えて、構築と実行に時間がかかる統合テストも利用しましたが、関心のある特定の機能のみを実行します。
単体テストでコード カバレッジを測定するツールがいくつかあります。それらは、コードがテストされるだけでなく、完全にテストされることを保証するために、単体テストとともに不可欠な部分です。
他のすべては純粋な魔法です ;)
コードをリファクタリングしたい場合、定義上、変更がコードを壊したかどうかを伝える何らかの方法が必要です。神聖な洞察が欠けているので、ユニットテストはかなり良いツールだと思いますが、ymmv.
あなたの言っていることには少し同感です。私の新しいバグが単体テストで発見されることはめったにないという点で、私の経験は似ています。仮にあったとしても、バグが発見された後、バグが再発しないように単体テストが修正されます。
単体テストが役に立ったのは、(Java) クラスの設計です。クラスをテスト可能にするためにクラスをリファクタリングすることがよくありました (たとえば、シングルトンの削除)。これにより、全体的な設計が改善されたと思います。私にとって、それはそれらを使用する十分な理由です。
私の経験では、ユニットテストは次のことを助けてくれました:
ただし、「一度に複数のものを管理すること」と「集中すること」が本当に苦手なので、これは私に少し関係しています。したがって、単体テストは私にとってはうまくいき、文字通り、新しい機能を導入して古い機能を壊してしまった私の一日を何度も救ってくれます。
これが当てはまらない場合は、使用しないでください。同じ量のバグで同じ結果、パフォーマンス、および品質が得られている場合は、単体テストは必要ありません。または、単体テストの方法論を修正する必要があります。
PSあなたのバグ率とあなたが言ったことに基づいて、とにかくあなたは天才のように聞こえます（これらが中規模または大規模なプロジェクトであると仮定して）ので、ユニットテストを使用しないでください。あなたはうまくやっているようです. しかし、私のように天才ではない世界の人々には、Unit Test を強くお勧めします。
あなたのことはわかりませんが、単体テストでキャッチされた既存のコードの変更によって作成された 2 つのコアダンプの 2 つの修正をチェックインしました。そして、ユニットテストの結果をもっと信頼していれば、ユニットテストでキャッチされたであろう主要な生産上の問題がありました（私たちのユニットテストは、私が認めたいよりも機能面で少しです）。
一般的なテスト ツールを使用した正式な単体テストは、米国の空港のセキュリティにかなり似ているように思えます。
ソフトウェアに対する考え方は人それぞれだと思います。私の意見では、ソフトウェアはお金を稼ぐ手段です (うまくいけば、収益の増加またはお金の節約によって)。質問に答える科学的な方法として最も近い TDD の投稿を見てきましたが、その方法論には科学的な厳密さが欠けています。指定された記事のいずれも、ベースラインまたはかなり対照的な代替方法を持っていませんでした.
正式な単体テストのファンは、引き続き自分たちのやり方で安心できると思います。私は紙切れにスペックを書き続け、聖アントニウス像の足元にあるボウルに入れ、祈りを捧げます。どちらの方法がより効果的かは誰にもわかりませんが、私の方法は確かに気持ちがいいです... 多分私はそれについてホワイトペーパーを書きます.
70年代と80年代のヘアカットと服の人気の高まりを覚えておいてください...それはそれらの数十年に住んでいた私たちにとってはあまりうまくいきませんでした。
正式な単体テストは、維持するためにかなりの作業と労力を要します。実際にソフトウェアを開発するのにかかる時間の20〜50％かかると思います。私が求めているのは、すべての開発作業に20〜50％のオーバーヘッドを追加するという既知の価格であり、注目に値する、および/または証明可能な利益です。
正式な単体テストを行わないことで、開発者はテストする適切なことを検討する必要があります。開発者は製品のより多くの所有権を取得します。
正式な単体テストはスネークオイルジュースのように聞こえます...みんなと彼の兄弟はそれが良い、便利、クールなどだと言いますが、それが実際に時間やお金を節約することを証明するランダム化比較試験はありません。これまでのすべての応答は主観的な証言です。
私が知りたいのは、単体テストの導入後、より高い生産性（またはさらに高い品質）を実証できるソフトウェアマネージャーがいるかどうかです。
笑-S.Lottによるファセットな暴言は最高ランクの回答です...このフォーラムは匿名です（とにかく私にとって）ので、あなたの尊敬は私が求めているものではありません。私は自分自身を平凡なものをかろうじて上回っていると思います。私は例外的な開発者と協力してきました...それらの人は一般的に彼らのコードの基本的なテストさえしません-彼らはそれがうまくいくことを知っているだけです。