単体テストが非常に優れている場合、なぜそれを行う企業が増えないのですか？[閉まっている]

私が最初に働いた実際のソフトウェア会社はすべてユニットテスト（NUnit）に関するものでした。当時、私たちが本当の意味でのステッカーだったのかはわかりません。コードカバレッジがどのようなものであるかわからないので、ほとんどの単体テストを作成していました。それ以来、私は多くのテストを行ういくつかの企業に出くわしましたが、それは椅子のテストです。そこにいる人に依存しているため、再現性が低く、バグをキャッチする可能性が低くなっています。もう1つの態度は、「将来的に」彼らがやりたかったことでした。基本的にお金が空から落ちるとき。

ユニットテストに失敗しました。これにより、作業が楽になります。しかし、私は新しい仕事を探すときに、ユニットテストは企業が将来的に「やり遂げたい」ものか、まったく行わないものであることに気づきました（ええと、それはしばらくの間存在しています今！）過去2年間に私が見た求人の60〜75％には、単体テストがまったく記載されていないと思います。私は、単体テストの経験が1つまたは2つあることだけを要件として考えることができます（中間レベルの開発者のポジションの場合）。

だから問題は、何が欠けているのですか？それは人々の生産性を向上させると思いますが、それは実際にそれを行うために確かな時間を費やした後にのみです。単体テストのコスト削減についての良い研究はありませんか？私が見ている種類の会社ですか？

編集：タイトルは少し悪魔の支持者ですが、私は自分自身を単体テストの支持者と考えています。

私の経験では、これにはいくつかの要因が関係しています。

1. 経営陣は、ユニットテストが実際に何であるか、なぜユニットテストに真の本質的な価値があるのか​​を理解していません。
2. 経営陣は製品の迅速な納品に関心を寄せる傾向があり、ユニットテストはその目標に対して逆効果であると（誤って）考えています。
3. テストはQAのみに属しているという誤解があります。開発者はコーダーであり、テストを書くことはできません。
4. ツールが無料で利用できるという事実にもかかわらず、管理者がユニットテストを正しく行うためにお金を費やす必要があるという一般的な誤解があります。（もちろん、開発者は検討する時間を増やしますが、それは実際には法外なものではありません。）
5. ウィルの答えはこの答えを丸めるでしょう：テストコードの価値を決定することは非常に難しいです（jcollumを編集してください）

当然、他の要因もありますが、それらは私がこれまでに遭遇したものにすぎません。

1）難しい
2）時間がかかる
3）テストコードの値を決定するのが非常に難しい

ポイント3は付箋です。優れた単体テストはバグを減らします。しかし、良い製品コードもそうです。単体テストのために存在しないバグの数をどのように判断しますか？存在しないものは測定できません。調査を指摘することはできますが、それらはビジネスマネージャーのスプレッドシートにうまく適合しません。

「管理」についてすべての責任を負うのは簡単です。しかし、経営陣は本当にユニットテストを特に行わないようにあなたに言っているのですか？

管理は、それがモジュール化であるか、抽象データ型であるか、デザインパターンであるか、ユニットテストであるかに関係なく、一般に、どのように仕事をするかを教えてくれません（おそらくすべきではありません）。これらは優れた有能なソフトウェアエンジニアが適用する貿易ツールですが、下手なエンジニアは適用しません。

私はあなたの質問に対する本当の答えは次のとおりだと思います：ユニットテストは本当に難しく、コンピューターサイエンスの学生はそのためのトレーニングを受けていません。

独自の文字列クラスを作成するのは簡単です。実際の製品をテストしているときに、パワーポイントのスライドで誰も言わなかった課題に遭遇します。

• ユーザーとの対話。アプリケーションの半分はユーザーインターフェイスロジックです。ボタンを動かしても故障しない、自動化された方法でそれをどのようにテストしますか？
• 外部APIおよびフレームワークとの相互作用。Windowsカーネルドライバーを作成している場合、それをどのように単体テストしますか？使用するすべてのIRPおよびカーネル関数のスタブを記述して、OSカーネルのシミュレーションを効果的に作成していますか？
• ネットワーク通信は21世紀のものです。複数の分散コンポーネントで構成される単体テストをどのように調整しますか？
• どのようにして良いテストケースを選びますか？私は一般に、「1000回のループでランダムなことを行い、それが壊れるかどうかを確認する」アプローチを試みている人をよく見ます。これを行うと、労力がリターンより高くなり、重要なバグが見落とされ、単体テストが中止されます。
• パフォーマンス要件が満たされていることをどのようにテストしますか？
• テストのパターンに関する知識は乏しいです。スタブ、定型応答、回帰テストは、ほとんどの人が知らない概念です。職場で実際にユニットテストに関する本を読んでいる人は何人いますか。

管理のせいにできる1つのことは、要件仕様に成果物の品質レベルに関する要件がほとんど含まれていないことです。

次に上司から時間の見積もりを求められたら、ユニットテストを作成する時間を含めて、何が起こるかを確認します。

ほとんどのテストは何もテストしません。
fileopen（）関数と、ファイルが存在しない場合は失敗し、ファイルが存在する場合は成功する単体テストを記述します。すごい！次に、BIG5中国語のファイル名で機能するかどうかを確認しましたか？NFS共有で？USBキー上のファイルとUACがオンになっているビスタで？

問題は、ユニットテストが、関数を作成した同じプログラマーによって、同じ一連の仮定と同じレベルのスキルで書かれていることです。実際に機能させるには、テストを他の誰かが作成し、公開された仕様に対してのみ、コードを表示しないようにする必要があります。-ほとんどの企業では、仕様書を入手するだけで画期的なことになります。

単体テストは、個々の関数のコードのエラーをチェックします。入力/出力がよく知られていて、内部構造が複雑であるデータアクセスレイヤー、数学ライブラリなどで機能しますが、多くの場合、それらは時間の無駄です。
エラーの原因がコードのさまざまな部分間の相互作用や、OSとユーザーとの相互作用である場合、エラーになります。高/低DPI設定がダイアログボックスをめちゃくちゃにする、または「。」を入れ替える外国語設定などの問題 と「、」は通常見つかりません。

単体テストのROIに関する調査が行われています。この質問を参照してください。

単体テストに興味のない開発者をたくさん見つけました。始めたとき、それは常に多くの仕事のようで、ほとんど見返りがありません。誰も余分な仕事にサインアップしたくないので、彼らは抵抗します。いったん人々が始めると、彼らはたいてい熱心にそれに固執しますが、彼らを始めるのは難しい場合があります。

単体テストの採用の問題は別として、単体テストは常に適切であるとは限りませんが、一般に価値があるとは限りません。ユニットテストについては、貧弱な構造に対して脆弱になるのを防ぐ特別なことは何もありません。

単体テストにはコスト（作成、保守、実行）があり、それらのコストよりも大きなメリットが得られる場合にのみ価値があります。テストの作成は他のスキルと同じで、成功するには特定の経験と知識が必要です。十分な経験がなければ、経験の浅い開発者でも、価値のない低品質、低価値、または高コストの単体テストを作成するのは非常に簡単です。特に、単体テストの価値を判断するのがいかに難しいかを考えると、そうです。

さらに、ユニットテストはコードの品質を向上させる1つの方法にすぎませんが、それだけが方法ではありません。状況やチームによっては、ソフトウェアの品質を向上させるための最も効果的な方法ではない場合があります。

単体テストに多大な労力を費やすことは、高品質のソフトウェアを保証するものではないことに注意してください。また、ユニットテストをまったく行わなくても、最高品質のソフトウェアを作成できます。

まあ、私の会社はTDDや単体テストを行っていません。正直なところ、その方法はわかりません。CapitalizeString（）のような愚かな関数に対しては明らかにそれを行うことができますが、複雑なオブジェクトを含む非常に複雑なシステムに対してそれを行う方法はわかりません。さらに、インタビューを受けた人々のほとんどは、経験がないか、経験が限られています。ユニットテストはSOの群衆から見て大きなもののようですが、利用可能なワークプールでは特に大きなものではありません。

TDDは別のトピックです。私たちはTDDに道徳的に反対しています。私たちはカウボーイコーダーではありませんが、プロジェクトの創造性と柔軟性を妨げると信じています。さらに、単体テスト機能を作成したコーダーがいても意味がありません。何かをするときは、考えられるすべてのエッジケースにコードを記述します。私が必要としているのは、見逃したかもしれないものを探すための別の頭脳です。それはありません。チームは小さく、自己完結型です。

要するに、私たちはTDDを信じていませんが、単体テストをしたいと考えています。経験がなく、簡単に見つけることができません。

ベストプラクティスに沿って実際に何もしない企業はたくさんあります。コードのレビューも、単体テストも、テスト計画も、何もない、ズボンの座席だけで。

これを機会に、継続的インテグレーションプラットフォームを使用してユニットテストを開発してもらいます。コードの品質と安定性を同時に向上させる力を印象付ける簡単な方法

編集：理由としては、CIとユニットテストを非常に簡単にする現在のツールを知らないだけだと思います。

私は怠惰が悪いユニットテストの根本的な原因だとは思いません。私の会社では、時間の制約と「ただやり遂げる」態度が単体テストを行うための最大の抑止力です。また、システムが故障する場所は、「ユニットレベル」ではなく、統合レベル（サービス、データベースアクセス、テストに特定のデータを必要とする複雑なクエリ）である傾向があります。これらのことはテストするのが難しいだけであり、機能を完成させるのに十分な時間がなければ、有用なテストを同時に実行する時間はおそらくないでしょう。

ユニットテストは、コンパイラと同様に、コード開発ワークフローの自然な部分にすぎません。

ただし、これには、ユニットテストの利点について管理者を教育する必要があります。ただし、ジュニア開発者はそのような影響を与える可能性は比較的低いです。したがって、企業がユニットテストの支持者であるかどうかは、ユニットテストの提唱者である上級開発者またはアーキテクトがいるかどうかに依存します。

これは、「何が欠けているのか、なぜユニットテストを行う企業が増えないのか」という質問への答えだと思います。:-)

それはおそらくあなたがすでに言及したいくつかのことの組み合わせです。TDDのコスト削減を測定することは困難です。ITをアウトソーシングしたい場合は、スタッフのスタッフに年間支払う金額と、契約するコストを示すことができます。その非常に具体的です。「このテストでは、デバッグと修正に4時間かかったバグをキャッチしました...」

いくつかの場所がそれを使用しない理由は、単に開始するためにも継続するためにも多くの作業を必要とするからです。単体テストの作成に実際の機能を作成するのと同じくらいの時間がかかるという事実は、開発者の生産性を半分に削減しているような一部のマネージャーにとっては思えます。

その上で、インフラストラクチャを配置して維持する必要があるチーム（または誰か）を構築します。

そして、アランが言うように、多くの場所は単にベストプラクティスを使用していない-彼らは単に具体的な何かを見たいと思っている。

私が見たところから、多くの企業が、実際には単体テストができない巨大で高度に結合されたコードベースを持っています。また、テスト可能な要件が適切ではないため、単体テストでは、「構築されたまま」の事実上の要件に対してテストを実行します。

プログラマーはただそれを始めなければならないと思います。最初にいくつかの簡単なテストを行うと、開発の一環として簡単に正当化できます。

高速なデバッグを実現するには、ユニットテストのようなものがほとんど常に必要です。正しい入力の配置、デバッガーのブレークポイントの設定、アプリケーションの起動などよりも、テストの起動がどれだけ速いかを説明してください。

コードにテストを文書化します。テストの場所と実行方法を説明するコメントを入力してください。将来のプログラマーはそれを見て、うまくいけばテストが広がるでしょう！

ユニットテストは、ほとんどの人が聞いたブラックボックス用語の1つですが、ユニットテストを正確に構成するもの、開始する場所、それらの記述方法、実際にテストを実行する方法、正確にテストする必要があるものなどがわかりません。等々

多くの場合、不確かな開発者にとっては、「エンタープライズレベルの開発者」だけが必要とするアイシングを不必要またはアイシングとして単に却下する方が簡単です。

私はユニットテストの大ファンであり、さまざまなクライアントタイプの契約開発プロジェクトを行う会社のパートナーでもあります。1か月以内に、サイズの異なる3〜4種類のプロジェクトに触れます。

プロジェクトが1回限りのように思える場合、単体テストはビジネスに利益をもたらさないため、単体テストに多額の投資をするつもりはありません。これらのタイプのプロジェクトでは、私が不確か/なじみのないもの、または頻繁に変更される可能性があるもの（制御できないデータソースのパーサーなど）を単体テストします。

一方、私が構築するのは、寿命が長くなることがわかっている、より大きな作品である、複数回の反復作業を行う、またはエラーが発生した場合にクライアントに大きな影響を与える、私はより多くのユニットテストに投資するつもりです。繰り返しになりますが、テストの優先順位は、不確実/なじみのない/変更するコードを中心に展開します。

ユニットテストは、タスクの複雑さ、および成果が出るかどうかを中心に展開すべきだと思います。慣れない追加のコードを書く意味はありません。

私の経験では、それはあなたが書いているソフトウェアに本当に依存しています。UIの単体テストを書くのは非常に難しいことに気づきました。私は、システムの特定の入出力がある部分に対してのみユニットテストを使用します。

ユニットテストに失敗しました。これにより、作業が楽になります。

これは、企業が単体テストを採用する十分な理由ではありません。

十分な理由は、「安価」（および/または「より良い」）かもしれません。これは、単体テストについて証明するのが簡単ではありません。

唯一の正当な理由は、「ユニットテストを書くことが開発者の時間を最大限に活用すること」である可能性があり、IMOを証明するのは非常に困難です。また、一部のソフトウェアや一部の開発者にとってはそうであり、他の場所ではそうではない場合もあります。

ユニットテストの世界を考えていない開発者がたくさんあります（たとえば、自動化された統合/機能テスト）をテストの他の形態は、より安く、より多くの価値があると思う人も含めて、例えばアム私は「doesnの唯一devが単体テストは好きですか？

もちろん、理想的な世界では、単体テストがあると主張することはできません。

ただし、単体テストを作成するかどうかは、さまざまな要因によって異なります。

• ソフトウェアの使用方法。自分だけのソフトウェアを作成している場合、単体テストを作成しますか？おそらく違います。市販されているパッケージ化されたソフトウェアを作成している場合は、おそらくそうです。

• コードを管理している人の数....それがあなただけの場合、変更を加えた後、コードをすばやく実行するだけで問題が発生しないことを確認するのに十分であると確信できます。もともとコードを記述していなかった他の人がコードを保守する必要がある場合、ユニットテストは、大きなコード（明らかにユニットテストでキャプチャされなかった！）を修正するためにコードを更新するときに、何も壊していないことを確信させるのに役立ちます。 。

• コードの複雑さ：テストが必要なテストコードのみ。1行の変数割り当てメソッドはテストを必要としません。実行の複数のパスを持つ50行のメソッドはおそらくそうです。

• 実用的な商業上の考慮事項：実際には、単体テストの記述には、そうしない場合よりも時間がかかります。プロトタイプソフトウェアを作成していて、商業的に将来が不確かな場合、十分に機能するコードをすぐに実行することと、2週間で単体テストされたコードを機能させることで、より効果的に機能することの間に、見返りがあります。ソフトウェアのような短い棚があり、次のプロジェクトに進むかどうかをすばやく（消費者の欲求を）確認することは、時には価値があります。

そして、他の人が指摘したように、テストはそれを書いた人と同じくらい良いです。

主な理由は、多くの開発者や開発マネージャーは、単体テストが存在するかどうか、またはそれらの使用方法を知る手がかりがないためです。

2番目の理由は、単体テストは、ある程度の品質基準をすでに満たしているコードでのみ（賢明な方法で）使用できることです。おそらく、いくつかの既存のコードベースはそのカテゴリーに分類されないでしょう。

3番目の理由は、怠惰および/または安さです。

単体テストは、テスト可能なコードを記述した場合にのみ役立つためです。そして、テスト可能なコードを書くのは難しいです。そして人々は怠惰でそして/または安いです。

編集：微妙な「怠惰」を「遅延および/または安価」として; まれなケースですが、実際にはスキルと能力を備えており、テストを作成することもありますが、収益をより直接的に左右する別の方法があります。

問題の一部は、開発者がビジネスの人々に同じ値のセットを持ち、「単体テストをすべきかどうか」に対する答えを本当に気にすることを期待していることだと思います。アセンブリ言語ではなく高級言語を使用することをビジネスから事前に承認することはありません。これは通常、作業を完了するための賢明な方法です。

ポイントは、ある私たちは（私たちのすべてがトピックに関する同じ知識を持っていると言っているわけではない）呼び出しを行う資格だけです。さらに、ポリシーの問題として、チームがユニットテスト（またはその日の名前付け）を行わない場合でも、通常、それが不可能であるとは限りません。

真実は、細かい細かさで行うほとんどのことのROIを実際に証明することはできないということです。なぜユニットテストがこの不合理で非典型的な証明基準に準拠しているのかは、私には理解できません...

人々は怠惰であり、強制されたときにのみ変化を採用します。

私の2セント：

• ある程度の教育と訓練が必要ですが、新卒者にはすでに適切な知識が備わっています。
• テストのオーバーヘッドは、より優れたツールで削減でき、これも発生しています（リファクタリングなど）。

ですから、それは時間の問題です。

ボブ・マーティンが次のように主張するマーティン・コプリエン論争があります：

「現在、開発者がユニットテストで実行していないコード行を出荷することは無責任です。」

[ http://www.infoq.com/interviews/coplien-martin-tdd]

テストで全員を売りたい場合は、次のようにします。

1. たくさんのテストを書いてください。
2. コードを変更してテストに失敗した他の開発者に通知します。
3. 彼らはコードを修正します。
4. これで、これらの特定のバグなしでリリースできます。

マネージャーでさえこれを理解することができました。

企業はユニットテストを実行していません。これは、多くのWebサイトが不適切に記述されているのと同じ理由で、無知であり、人々は古い習慣に固執しています。私の会社では、ユニットテスト（NunitとTypemockを使用）を開始したため、コードカバレッジが高くなり、製品化までの時間を短縮できます。

ほとんどの優れたアイデアと同様に、採用もアイデアの質よりも組織のパスへの依存に関係しています。

製品を出荷したほとんどの企業では、上級レベルのQAヘッドを擁する実質的なQA部門が作成されています。テストはQAチームの責任です。

同社は通常、QAチームにヘビーデューティコーダーを配置しないため、ユニットテストコードを記述する可能性は低いです。

プログラミングチームは、QAチームとの競合を引き起こすため、テストコードの記述に消極的です。

QAが別の職務に振り分けられていないグループでのユニットテストの採用と関心が高まっています。

単体テストの作成と更新には費用がかかります。ほとんどの企業では、以前のソフトウェアに単体テストがなく、作成するにはコストがかかりすぎます。したがって、彼らはそれを行わず、開発プロセスに時間を追加するため、新機能にも追加しません。

ほとんどの企業は役に立たない。明らかにあなた（または私）が働いている人ではありません。