単体テストとテストなしの開発の時間差

私は、かなり時間に制約のある作業環境を持つソロ開発者です。開発時間は、要件、緊急度、またはその両方に応じて、プロジェクトごとに通常1〜4週間です。常に3〜4個のプロジェクトを処理していますが、一部のプロジェクトではタイムラインが重複しています。

予想通り、コードの品質が低下します。また、正式なテストも行っていません。通常、システムが多少壊れるまで、システムを歩いて行きます。その結果、かなりの量のバグが本番環境に逃げてしまいます。これを修正する必要があり、その結果、他のプロジェクトが滞ります。

これがユニットテストの出番です。正しく行われると、本番環境に逃げるバグはもちろん、バグを最小限に抑えることができます。一方、テストの作成にはかなりの時間がかかる可能性がありますが、これは私のような時間に制約のあるプロジェクトでは適切に聞こえません。

質問は、単体テスト済みのコードを未テストのコードと比べてどのくらいの時間差で書くか、そしてプロジェクトの範囲が拡大するにつれてその時間差はどのように拡大するのでしょうか？

後でテストするほど、テストの作成にかかるコストが高くなります。

バグの寿命が長いほど、修正に費用がかかります。

収益の減少の法則により、バグがないことを確認するために忘却に身を任せることができます。

仏は中道の知恵を教えました。テストは良いです。あまりにも良いことのようなものがあります。重要なのは、バランスが崩れていることを知ることができることです。

テストなしで記述するコードの各行は、コードを記述する前にテストを記述した場合よりも、後でテストを追加するためのコストが大幅に高くなります。

テストなしのコードの各行は、デバッグまたは書き換えが非常に難しくなります。

作成するすべてのテストには時間がかかります。

すべてのバグは修正に時間がかかります。

忠実な人は、最初に失敗したテストを書かずにコードを1行も書かないことを教えてくれます。このテストにより、期待どおりの動作が得られることが保証されます。テストにより動作が同じであることが証明されるため、システムの他の部分に影響を与えることを心配することなく、コードをすばやく変更できます。

テストでは機能が追加されないという事実に対して、これらすべてを比較検討する必要があります。製品コードは機能を追加します。そして、機能は請求書を支払うものです。

実用的に言えば、私が取り除けるすべてのテストを追加します。私はテストを見ることに賛成してコメントを無視します。私は、コードが信じていることをするためのコードすら信用していません。テストを信頼しています。しかし、私はたまにhメアリーを投げてラッキーになることが知られています。

ただし、成功したコーダーの多くはTDDを行いません。それは彼らがテストしないという意味ではありません。彼らは、コードのすべての行がそれに対して自動化されたテストを持っていることを強引に主張しません。ボブおじさんでさえ、UIをテストしていないことを認めています。彼はまた、すべてのロジックをUIから外すように主張しています。

フットボールの比phor（つまりアメリカンフットボール）として、TDDは優れたグラウンドゲームです。あなたがコードの山を書いて、それが機能することを望んでいる場合の手動のみのテストは、成功するゲームです。どちらでも得意です。両方を行うことができない限り、あなたのキャリアはプレーオフになりません。それぞれを選択するタイミングを学ぶまで、スーパーボウルは作成されません。しかし、特定の方向にナッジが必要な場合：私が追い越しているとき、役人の呼び出しはより頻繁に私に反対します。

TDDを試してみたい場合は、職場で行う前に練習することを強くお勧めします。TDDが途中で、半分で、半分で、そして半ば嫌悪されたことが、一部の人がそれを尊重しない大きな理由です。1杯の水を別のコップに注ぐようなものです。コミットせずにすばやく完全に行うと、テーブル全体に水が滴り落ちることになります。

私は残りの答えに同意しますが、時差問題とは何かに直接答えることです。

Roy Osheroveの著書The Art of Unit Testing、Second Edition 200ページでは、1つのチームがテストを行い、もう1つのチームはテストを行わなかった2人の異なるクライアント向けに、同じサイズのプロジェクトを同じチーム（スキルに関して）で実装する事例研究を行いました

彼の結果は次のようでした。

したがって、プロジェクトの最後には、時間とバグの両方が少なくなります。もちろん、これはプロジェクトの大きさに依存します。

私が知っている「現実世界の設定」でこれを研究した研究は1つだけです。テスト駆動開発による品質改善の実現：4つの産業チームの結果と経験です。基本的に、同じソフトウェアを同じチームで2回（または理想的にはもっと頻繁に）開発し、1つを除いてすべてを捨てる必要があるため、賢明な方法でこれを行うのは高価です。

この調査の結果、開発時間は15％〜35％増加し（TDD評論家がしばしば引用する2倍の数字に近い）、リリース前の欠陥密度は40％〜90％に減少しました（！ ）。すべてのチームにはTDDの経験がないため、時間の増加は少なくとも部分的に学習に起因すると考えられ、時間の経過とともにさらに低下すると考えられますが、この調査では評価されませんでした。

この研究はTDDに関するものであり、あなたの質問はユニットテストに関するものであることに注意してください。

うまく行けば、ユニットテストを使用した開発は、補足されたバグの利点を考慮しなくても高速になります。

実際、私はコードをコンパイルするとすぐに動作するだけのコーダーではありません。コードを作成/変更するときは、コードを実行して、意図したとおりに動作することを確認する必要があります。あるプロジェクトでは、これは次のようになる傾向がありました。

1. コードを修正する
2. アプリケーションをコンパイルする
3. アプリケーションを実行する
4. アプリケーションにログインする
5. ウィンドウを開く
6. 別のウィンドウを開くには、そのウィンドウからアイテムを選択します
7. そのウィンドウにいくつかのコントロールを設定し、ボタンをクリックします

そしてもちろん、結局のところ、実際に正しく機能させるには通常数回の往復が必要でした。

さて、単体テストを使用している場合はどうなりますか？次に、プロセスは次のようになります。

1. テストを書く
2. テストを実行し、予想どおりに失敗することを確認します
3. コードを書く
4. テストを再度実行し、合格することを確認します

これは、アプリケーションを手動でテストするよりも簡単で高速です。私はまだアプリケーションを手動で実行する必要があります（したがって、実際にはまったく機能しない作業を開始するとき、私はばかげて見えることはありません）その時点で検証します。実際に保存するときにテストを自動的に再実行するプログラムを使用して、実際にこのループを実際にさらに厳密にします。

ただし、これはテストに適したコードベースでの作業に依存します。多くのプロジェクトは、多くのテストがあるプロジェクトであっても、テストの作成を難しくしています。しかし、あなたがそれに取り組むなら、手動テストよりも自動化テストでテストする方が簡単なコードベースを持つことができます。ボーナスとして、自動化されたテストを維持し、回帰を防ぐためにそれらを実行し続けることができます。

すでに多くの回答がありますが、それらは幾分反復的であり、別のタックを取りたいと思います。単体テストは、ビジネス価値を高める場合にのみ価値があります。テストのためにテスト（簡単なテストまたはトートロジーテスト）、または任意のメトリック（コードカバレッジなど）を達成するためのテストは、貨物カルトプログラミングです。

テストは、書くのにかかる時間だけでなく、メンテナンスの面でもコストがかかります。それらは、テストするコードと同期を保つ必要があります。そうでなければ、価値がありません。すべての変更でそれらを実行する時間コストは言うまでもありません。それは契約を破る（または本当に必要なものを行わない言い訳）わけではありませんが、費用便益分析に織り込む必要があります。

したがって、関数/メソッドをテストするかどうか（またはどのようなものか）を決定する際に尋ねる質問は、「このテストで作成/保護するエンドユーザーの価値は何か？」もしあなたがその質問に答えられないなら、頭のてっぺんから外れて、そのテストは書く/維持するコストの価値はないでしょう。（またはあなたがある問題領域、理解していないメーリングリストのテストの欠如よりも大きな問題を）。

http://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

それは、人と、作業しているコードの複雑さと形に依存します。

私にとって、ほとんどのプロジェクトでは、単体テストを書くことで、作業が約25％速くなります。はい、テストを書く時間も含めて。

問題の事実は、コードを記述するときにソフトウェアが実行されないということです。顧客にそれを出荷し、彼らがそれに満足しているときに行われます。ユニットテストは、ほとんどのバグをキャッチし、デバッグのためにほとんどのバグを分離し、コードが良好であるという自信を得るために、私が知っている最も効率的な方法です。とにかくこれらのことをしなければならないので、うまくやる。

質問は、単体テスト済みのコードを未テストのコードと比べてどのくらいの時間差で書くか、そしてプロジェクトの範囲が拡大するにつれてその時間差はどのように拡大するのでしょうか？

問題はプロジェクトの年齢が上がるにつれて悪化します。なぜなら、新しい機能を追加したり、既存の実装をリファクタリングしたりするときはいつでも、以前にテストしたものを再テストして、機能することを確認するためです。そのため、長寿命（複数年）プロジェクトの場合、機能をテストするだけでなく、100回以上再テストする必要があります。このため、自動テストを行うことでメリットが得られる場合があります。ただし、IMOでは、これらが自動化された単体テストではなく、自動化されたシステムテストであれば十分です（または、さらに優れています）。

2番目の問題は、バグが早期に発見されないと、バグを見つけて修正するのが難しくなる可能性があることです。たとえば、システムにバグがあり、最新の変更を行う前に完全に機能していたことがわかっている場合は、最新の変更に注意を集中して、バグの導入方法を確認します。しかし、最新の変更を行う前にシステムが動作していたことがわからない場合（最新の変更前にシステムが適切にテストされなかったため）、バグはどこにでもある可能性があります。

上記は特に深いコードに適用され、浅いコードにはあまり適用されません。たとえば、新しいページが既存のページに影響を与える可能性が低い新しいWebページを追加する場合です。

その結果、かなりの量のバグが本番環境に逃げてしまいます。これを修正する必要があり、その結果、他のプロジェクトが滞ります。

私の経験ではそれは受け入れられないだろうし、あなたは間違った質問をしている。テストが開発を高速化するかどうかを尋ねる代わりに、何が開発をよりバグフリーにするのかを尋ねるべきです。

より良い質問があります：

• ユニットテストは適切な種類のテストであり、これまで作成してきた「かなりの量のバグ」を回避する必要がありますか？
• 推奨される他の品質管理/改善メカニズム（単体テスト以外）はありますか？

学習は2段階のプロセスです。十分に学習することを学習してから、より迅速に学習することを学習します。

考慮すべきいくつかの側面。他の回答には記載されていません。

• 追加特典/追加費用は、単体テストの作成経験に依存します
  • 最初の単体テストプロジェクトでは、多くのことを学ぶ必要があり、多くの間違いを犯したため、追加費用が3倍になりました。
  • tddでの10年の経験の後、事前にテストを書くために25％のコーディング時間が必要です。
• より多くのtdd-modulsを使用すると、手動GUIテストと統合テストの必要性がまだあります
• tddは最初から実行した場合にのみ機能します。
  • 既存の成長したプロジェクトにtddを適用すると、費用がかかり、困難になります。ただし、代わりに回帰テストを実装できます。
• 自動化されたテスト（単体テストおよびその他の種類のテスト）では、maintanace constが機能し続ける必要があります。
  • コピー＆ペーストでテストを作成すると、testcode-maintanaceが高価になる可能性があります。
  • テストコードの経験が増えると、テストコードはよりモジュール化され、保守が容易になります。
• 経験が増えれば、自動テストを作成する価値がある場合とそうでない場合の感覚が得られます。
  • 例：単純なゲッター/セッター/ラッパーを単体テストすることには大きな利点はありません
  • GUIを使用して自動テストを作成しません
  • ビジネスレイヤーをテストできるように注意します

概要

tddで開始する場合、特に「時間に制約のある作業環境」の下にいる限り、「費用よりも利益」の状態に到達するのは困難です。「高価で役に立たない」テストのもの」

注：「単体テスト」とは、「モジュールを単独でテストする」ことを意味します。

注：「回帰テスト」では

• 出力テキストを生成するコードを記述します。
• 生成の結果がまだ同じではないことを検証する「回帰テスト」コードを作成します。
• 回帰テストは、結果が変わるたびに通知します（大丈夫かもしれませんし、新しいバグの指標かもしれません）
• 「回帰テスト」の考え方は承認テストに似ています
  • ...結果のスナップショットを取得し、それらが変更されていないことを確認します。

プログラマーは、ほとんどのタスクを処理する人々と同様に、実際に完了するまでにかかる時間を過小評価しています。それを念頭に置いて、テストを書くのに10分を費やすことは、実際にはテスト中にやった同じ関数名とパラメーターを考え出すのにその時間を費やしていたときに大量のコードを書くのに費やした時間と見なすことができます。これはTDDシナリオです。

テストを書くことは、クレジットカードを持っているようなものです。より多くの費用をかけたり、より多くのコードを書いたりする傾向があります。コードが増えるとバグも増えます。

完全にコードをカバーするか、まったくカバーしないかを決定する代わりに、アプリケーションの重要かつ複雑な部分に焦点を合わせ、そこでテストすることをお勧めします。銀行のアプリでは、それは利息の計算かもしれません。エンジン診断ツールには、複雑なキャリブレーションプロトコルがあります。あなたがプロジェクトに取り組んできたなら、あなたはおそらくそれが何であり、バグがどこにあるか知っているでしょう。

ゆっくり始めてください。判断する前に流someに話してください。いつでも停止できます。

プログラマーボードがTDDやその他のテスト方法論を推進してきた長い歴史がありますが、それらの議論を思い出せず、それらに同意するつもりはありませんが、少し微妙な違いを考慮すべき追加事項を次に示します。

• テストは、コンテキストに応じて同様に便利で効率的ではありません。Webソフトウェアを開発しています。UI全体をテストするプログラムがあるかどうか教えてください...今、Excelマクロをプログラミングしています。VBAでテストモジュールを実際に開発する必要がありますか？
• テストソフトウェアの作成と保守は、短期的には重要な実際の作業です（長期的には成果があります）。関連するテストを書くことは、取得する専門知識でもあります
• チームとして作業し、単独で作業する場合、同じテスト要件はありません。なぜなら、チームでは、自分が書いていないコードを検証、理解、伝達する必要があるからです。

テストは良いと思いますが、早い段階でテストを行い、ゲインがどこにあるかをテストしてください。

TDDの見落とされがちな利点は、テストが変更を行うときに新しいバグを導入しないことを保証するための保護手段として機能することです。

TDDアプローチは、最初は間違いなく時間がかかりますが、重要なポイントは、コードの記述が少なくなるため、問題が発生する可能性が少なくなることです。当然のことながら、これらの機能はすべてコードベースには含まれません。

映画「ソードフィッシュ」には、記憶が役立った場合、ハッカーが銃で頭を動かし、うんざりする場面があります。重要なのは、ヘッドスペースがコードに含まれていて、顧客があなたや他の優先事項が絞られていると叫んでいる数ヶ月前よりもあなたの側に時間がある場合、作業がはるかに簡単であるということです。

開発者は、後でバグを修正する方がコストがかかることを理解していますが、それを頭に入れます。現在のコーディング方法で1日500ドル、TDDの方法で記述した場合は1000ドルを支払うことができれば、2回目のオファーをする人に手をかざすことになります。テストを雑用と見なすのをやめて、それをお金の節約になると見るほど、より良い結果が得られます。

私はあなたの経験に関連することができます-私たちのコードベースにはほとんどテストがなく、ほとんどテストできませんでした。何かを開発するには文字通り長い年月がかかり、プロダクションのバグを修正するには新しい機能から貴重な時間がかかりました。

部分的な書き換えのために、すべてのコア機能のテストを作成することを誓いました。最初はかなり長い時間がかかり、私の生産性は著しく低下しましたが、その後、私の生産性はかつてないほど向上しました。

その改善の一部は、プロダクションのバグが少なくなり、その結果、中断が少なくなったことです->いつでも集中できるようになりました。

さらに、コードを単独でテストおよびデバッグする能力は、実際に役に立ちます-テストのスイートは、手動セットアップを除いてデバッグできないシステムよりもはるかに優れています。数十回

しかし、最初は生産性が低下していることに注意してください。そのため、時間のプレッシャーが既に正気でないプロジェクトでテストを学び始めてください。また、グリーンフィールドプロジェクトで開始してみてください。レガシーコードのユニットテストは非常に難しく、優れたテストスイートがどのように見えるかを知っていると役立ちます。

以前の回答を補足するために、テストは目的そのものではないことを忘れないでください。テストを行う目的は、アプリケーションが進化を通じて、予期しないコンテキスト内などで期待どおりに動作することです。

したがって、テストを記述することは、エンティティのすべてのエンドポイントのすべての動作を証明することを意味しません。これは一般的なエラーです。多くの開発者は、すべての関数/オブジェクト/メソッド/プロパティ/などをテストする必要があると考えています。これにより、作業負荷が高くなり、無関係なコードとテストが大量に発生します。このアプローチは、ほとんどの開発者が全体的な動作を認識していないが、相互作用のドメインのみを見ることができる大きなプロジェクトで一般的です。

疎なリソースとテストを扱う際の正しいアプローチはかなり明白であり、常識ですが、一般的には正式ではありません。 テスト開発リソースを最初に高レベルの機能に投資し、徐々に特異性に落とし込みます。これは、ある時点で、孤独な開発者として、単体テストだけでなく、機能/統合などにも焦点を当てることになることを意味します。テストし、時間のリソースに応じて、計画および検討するように、主な単一機能に徐々に移行します。高レベルのテストは、低レベル/単体テストに対処し、所有するリソースに応じてテスト開発戦略を計画するために必要な情報を提供します。

たとえば、最初にブラックボックスとして処理チェーンをテストするとします。動作が極端な条件を考慮しなかったためにチェーンの一部のメンバーが失敗した場合、このメンバーだけでなく他のメンバーでも機能を保証するテストを作成します。次に配信します。次のサイクルでは、ネットワークに障害が発生することがあります。そのため、このような問題に対処するテストを、脆弱性のあるモジュールで作成します。等々。