ユニットテストは努力する価値がありますか？[閉まっている]

私が取り組んでいるチームの開発プロセスに単体テストを統合するために取り組んでおり、懐疑論者もいます。ユニットテストの価値についてチームの懐疑的な開発者を説得するいくつかの良い方法は何ですか？私の特定のケースでは、機能を追加したりバグを修正したりするときにユニットテストを追加します。残念ながら私たちのコードベースは簡単なテストには向いていません。

私たちのオフィスには毎日、次のようなやり取りがあります。

「まあ、私は単体テストが大好きです。何かが機能する方法に多くの変更を加えることができたので、もう一度テストを実行して、何も壊れていないことを確認できました...」

詳細は毎日変わりますが、感情は変わりません。単体テストとテスト駆動開発（TDD）には多くの隠された個人的な利点があるだけでなく、明らかなものもあるので、自分でやるまで実際に説明することはできません。

しかし、それを無視して、これが私の試みです！

1. 単体テストを使用すると、コードに大きな変更をすばやく加えることができます。テストを実行したので、今は機能していることがわかります。必要な変更を加えたら、テストを再度機能させる必要があります。これにより時間を節約できます。

2. TDDは、コーディングを停止するタイミングを理解するのに役立ちます。あなたのテストは、あなたが今のところ十分に行っており、微調整をやめて次のことに移ることができるという自信をあなたに与えます。

3. テストとコードは連携して、より良いコードを実現します。あなたのコードは悪い/バグがあるかもしれません。あなたのテストは悪い/バギーかもしれません。TDDでは、悪い/バギーの両方が低い可能性を利用しています。多くの場合、修正が必要なのはテストですが、それでも良い結果です。

4. TDDは便秘のコーディングに役立ちます。大規模で困難な作業に直面した場合、テストを作成することで、すばやく作業を進めることができます。

5. 単体テストは、作業しているコードの設計を本当に理解するのに役立ちます。何かを実行するためのコードを書く代わりに、コードの対象となるすべての条件と、そこから期待される出力の概要を説明します。

6. ユニットテストは、視覚的なフィードバックを即座に提供します。私たちは、すべての緑の信号が終わったときの感覚を気に入っています。とても満足です。また、中断した後に中断したところから再開する方がはるかに簡単です。修正が必要な次の赤いライトに到達したところがわかるからです。

7. 一般的な信念のユニットテストに反して、2倍のコードを記述したり、コーディングを遅くしたりすることはありません。コツをつかめば、テストなしのコーディングよりも高速で堅牢です。テストコード自体は通常比較的簡単であり、あなたがやっていることに大きなオーバーヘッドを追加しません。これはあなたがそれをしているときだけ信じられるものです:)

8. 「頻繁に実行される不完全なテストは、まったく記述されていない完全なテストよりもはるかに優れている」と言ったのはファウラーだったと思います。私はこれを、私のコードカバレッジの残りの部分がひどく不完全であっても、テストが最も役立つと思うテストを書く許可を与えていると解釈します。

9. 優れた単体テストは、何かが何をすべきかを文書化して定義するのに役立ちます

10. 単体テストはコードの再利用に役立ちます。コードとテストの両方を新しいプロジェクトに移行します。テストが再度実行されるまでコードを調整します。

私が関わっている多くの作業はユニットテスト（Webアプリケーションのユーザーインタラクションなど）には適していません。私はこのアプローチを十分に推薦することはできません。

単体テストは、ジムに行くのとよく似ています。 あなたはそれがあなたにとって良いことを知っています、すべての議論は理にかなっているので、あなたはトレーニングを始めます。最初のラッシュがありますが、それは素晴らしいことですが、数日後、トラブルに値するかどうか疑問に思い始めます。あなたは服を着替えてハムスターの車輪の上を走るのに一日のうち1時間を費やしていて、本当に足と腕の痛み以外のものを本当に得ているのか確信が持てません。

その後、おそらく1〜2週間後に、痛みが治まると同時に、ビッグデッドラインが近づき始めます。「有用な」仕事を終わらせるために起きているすべての時間を費やす必要があるので、ジムに行くような無関係なものを切り捨てます。あなたは習慣から外れ、ビッグデッドラインが終了するまでに、あなたはスクエアワンに戻ります。なんとかジムに戻ることができたら、初めて行ったときと同じように痛いです。

何かを読んで、何か間違ったことをしていないか確認します。あなたは、すべてのフィット感、運動の美徳を称賛する幸せな人々に少し不合理な悪意を感じ始めます。あなたは多くの共通点がないことに気づきます。ジムに行くために15分のドライブをする必要はありません。建物の中に1つあります。彼らは運動の利点について誰かと議論する必要はありません。それは、誰もが行うことであり、重要なこととして受け入れるものです。ビッグデッドラインが近づいても、上司が食べるのをやめるように要求する以上に運動は不要であるとは言われません。

したがって、あなたの質問に答えるために、ユニットテストは通常​​は努力する価値がありますが、必要な努力の量は誰にとっても同じになるとは限りません。実際にコード品質を重視し ていない会社でスパゲッティコードベースを扱っている場合、ユニットテストは膨大な労力を必要とする可能性があります。（多くのマネージャーが単体テストの賞賛を歌いますが、それは彼らがそれが重要なときにそれに固執するという意味ではありません。）

ユニットテストを仕事に取り入れようとしていて、期待していた太陽と虹がまったく見えない場合は、自分のせいにしないでください。ユニットテストを実際に機能させるには、新しい仕事を見つける必要があるかもしれません。

納得させるための最良の方法...バグを見つけ、そのための単体テストを記述し、バグを修正します。

その特定のバグが二度と発生する可能性は低く、テストでそれを証明できます。

これを十分に行うと、他の人がすぐに追いつくでしょう。

thetalkingwalnutは尋ねます：

ユニットテストの価値についてチームの懐疑的な開発者を説得するいくつかの良い方法は何ですか？

ここにいる誰もが、なぜユニットテストが優れているのか、という多くの理由を山積みにしようとしています。しかし、誰かに何かを説得する最善の方法は、彼らの議論に耳を傾け、ポイントごとにそれに対処することです。あなたが聞いて、彼らが彼らの懸念を言葉で説明するのを手伝うなら、あなたはそれぞれに対処し、おそらく彼らをあなたの視点に変えることができます（または、少なくとも、彼らに立つ足なしで彼らを残してください）。知るか？おそらく、ユニットテストがあなたの状況に適切でない理由を彼らは納得させるでしょう。可能性は低いですが、可能です。おそらく、ユニットテストに対する彼らの議論を投稿すれば、反論を特定するのに役立ちます。

議論の両側に耳を傾け、理解することが重要です。人々の懸念を考慮せずにユニットテストを熱心に採用しようとすると、宗教戦争（そしておそらく本当に価値のないユニットテスト）になってしまいます。それをゆっくりと採用し、最小のコストで最大のメリットが得られるところに適用することから始めれば、ユニットテストの価値を実証し、人々を説得する可能性が高まるでしょう。これは思ったほど簡単ではないことに気づきました。通常、説得力のある議論を行うにはある程度の時間と注意深い測定基準が必要です。

単体テストは他のツールと同様にツールであり、利点（バグの検出）がコスト（それらの記述にかかる労力）を上回るように適用する必要があります。それらが意味をなさない場合や使用しない場合は使用しないでください。これらはツール（たとえば、検査、アサーション、コードアナライザー、形式的メソッドなど）の一部にすぎないことを忘れないでください。私が開発者に言っているのはこれです：

1. メソッドのテストが必要でない理由（例：単純すぎて価値がない、または困難すぎて価値がない）とメソッドの検証方法（例：インスペクション、アサーション）が正しい場合、メソッドのテストの記述をスキップできます。 、正式な方法、インタラクティブ/統合テスト）。検査や正式な証明などの一部の検証は、ある時点で行われ、その後、製品コードが変更されるたびに繰り返す必要があることを考慮する必要があります。一方、単体テストとアサーションは、回帰テストとして使用できます（一度記述して、その後繰り返し実行します）。 ）。時々私はそれらに同意しますが、多くの場合、メソッドが本当に単純すぎるか、単体テストが難しすぎるかについて議論します。

   • メソッドが失敗して単純すぎるように思われると開発者が主張する場合、そのための単純な5行の単体テストを作成するのに必要な60秒かかるのではないでしょうか。これらの5行のコードは、翌年以上、毎晩実行されます（毎晩のビルドを行いますよね？）。たった一度でも、特定に15分以上かかった可能性のある問題を見つけた場合は、努力する価値があります。そしてデバッグ。さらに、簡単な単体テストを作成すると単体テストの数が増え、開発者は見栄えがよくなります。

   • 一方、開発者がメソッドを単体テストするのが難しすぎる（必要な大幅な作業に値しない）と主張する場合、それはおそらく、簡単な部分をテストするためにメソッドを分割またはリファクタリングする必要があることを示す良い兆候です。通常、これらは、シングルトン、現在時刻などの異常なリソース、またはデータベース結果セットなどの外部リソースに依存するメソッドです。これらのメソッドは通常、リソースを取得するメソッド（たとえばgetTime（）を呼び出す）とリソースを引数として受け取るメソッド（たとえば、タイムスタンプをパラメーターとして受け取る）にリファクタリングする必要があります。リソースを取得するメソッドのテストをスキップし、代わりに、リソースを引数として取るメソッドの単体テストを作成しました。通常、これにより単体テストの作成がはるかに簡単になるため、作成する価値があります。

2. 開発者は、ユニットテストの包括性について、「砂の中の線」を描く必要があります。開発の後半では、バグを見つけたときはいつでも、より包括的な単体テストで問題が検出されたかどうかを判断する必要があります。もしそうであり、そのようなバグが繰り返し出現する場合、彼らは将来的に（現在のバグのユニットテストの追加または拡張から始めて）より包括的なユニットテストを書くことに「行」を移動する必要があります。彼らは適切なバランスを見つける必要があります。

ユニットテストを実現するために、その重要な銀の弾丸ではなく、そこにあるあまりユニットテストなどのAの事は。私の職場では、学んだことをするたびに、「ユニットテストをもっと書く必要がある」と必ず耳にします。「単体テスト」==「良い」という頭の中に打ち込まれているため、経営陣はうなずきます。

ただし、「より多くの単体テスト」の影響を理解する必要があります。開発者は1週間に〜N行のコードしか記述できず、そのコードの何パーセントがユニットテストコードと製品コードのどちらになるかを把握する必要があります。緩い職場では、コードの10％が単体テストとして、コードの90％が製品コードとして含まれている可能性があり、（非常にバグの多い）機能が多数ある製品（MS Wordなど）があります。一方、90％の単体テストと10％の量産コードを持つ厳格なショップでは、機能が非常に少ない堅固な製品が得られます（ "vi"と考えてください）。後者の製品がクラッシュしたという報告を耳にすることは決してないかもしれませんが、それはおそらく、製品の販売がうまくいかず、コードの品質に関係しているためです。

さらに悪いことに、ソフトウェア開発における唯一の確実性は、「変更は避けられない」ということでしょう。厳密なショップ（90％のユニットテスト/ 10％の製品コード）が、2つの機能を備えた製品を作成するとします（製品コードの5％== 1の機能を想定）。顧客が来て機能の1つを変更すると、その変更によってコードの50％（ユニットテストの45％と製品コードの5％）が破棄されます。怠惰な店（10％の単体テスト/ 90％の製品コード）には18の機能がある製品があり、どれもうまく機能しません。顧客は、4つの機能の要件を完全に刷新します。変更は4倍の大きさですが、コードベースの半分しかゴミ箱に入れられません（約25％=約4.4％の単体テスト+本番用コードの20％）。

私の要点は、ユニットテストが少なすぎることと多すぎることのバランスを理解していることを伝える必要があるということです。仲間やその管理を納得させることができれば、信頼を得て、おそらく彼らを勝ち取る可能性が高まります。

私は何度も単体テストをいじっていましたが、自分の状況を考えると、努力する価値があるとまだ確信しています。

私はWebサイトを開発しています。そのロジックの多くには、データベース内のデータの作成、取得、更新が含まれます。単体テストの目的でデータベースを「モック」しようとしたところ、非常に面倒になり、少し無意味に思えました。

ビジネスロジックを中心に単体テストを作成したとき、それが長期的に見て本当に役に立ったことはありません。私は主にプロジェクトだけで作業しているので、自分が取り組んでいることによってコードのどの領域が影響を受けるかを直感的に知る傾向があり、これらの領域を手動でテストします。できるだけ早くクライアントにソリューションを提供したいのですが、ユニットテストは時間の無駄になりがちです。手動テストをリストし、自分でウォークスルーして、私が行くにつれてチェックを外します。

開発者のチームがプロジェクトに取り組み、お互いのコードを更新することは有益であることがわかりますが、それでも、開発者が高品質である場合、優れたコミュニケーションと十分に記述されたコードで十分であると思います。

ユニットテストの優れた点の1つは、コードがどのように動作するかについてのドキュメントとして機能することです。優れたテストはリファレンス実装のようなものであり、チームメイトはそれらを見て、自分のコードを自分のコードと統合する方法を確認できます。

ユニットテストは初期投資の価値があります。数年前に単体テストの使用を開始して以来、私はいくつかの本当の利点を見つけました：

• 回帰テストにより、コードに変更を加える恐れがなくなります（コードが機能するか、変更が加えられるたびに爆発するのを見るような暖かい輝きはありません）
• 他のチームメンバー向けの実行可能コードの例（および6か月後の自分）
• 容赦のないリファクタリング -これは非常にやりがいのあることです。試してみてください！

コードスニペットは、テスト作成のオーバーヘッドを減らすのに非常に役立ちます。クラスアウトラインと関連する単体テストフィクスチャを数秒で作成できるスニペットを作成することは難しくありません。

テストはできるだけ少なくする必要があります。

つまり、意図を明らかにするために必要なだけの単体テストを作成する必要があります。これはよく見落とされがちです。単体テストにはコストがかかります。変更を加えてテストを変更する必要がある場合は、俊敏性が低下します。単体テストは短く簡潔にしてください。それから彼らは多くの価値を持っています。

壊れることのない多くのテストが頻繁に見られます。大きくて不器用で、多くの価値を提供していないので、結果的に速度が低下します。

他の回答にはこれは見られませんでしたが、気づいたことの1つは、デバッグがはるかに高速にできることです。修正コードを取得するために正しい手順のシーケンスを使用してアプリをドリルダウンする必要はありません。ブールエラーが発生したことを見つけ、それをすべてもう一度実行する必要があるだけです。単体テストを使用すると、デバッグしているコードに直接ステップインできます。

[上に表示されないようにするポイントがあります]

「全員が単体テストを実施しているが、必ずしもそれを実現しているわけではない-FACT」

考えてみてください。文字列を解析して改行文字を削除する関数を記述します。初心者の開発者は、コマンドラインからMain（）に実装していくつかのケースを実行するか、視覚的なフロントエンドをボタンで打ち込み、関数をいくつかのテキストボックスとボタンに結び付けて、何が起こるのですか。

それは単体テストです。基本的でひどく組み立てられていますが、いくつかのケースでコードをテストします。

あなたはもっと複雑なものを書きます。（単体テスト）でいくつかのケースをスローし、コードをデバッグしてトレースすると、エラーがスローされます。値を調べて、正しいか間違っているかを判断します。これはある程度ユニットテストです。

ここでの単体テストは、実際にその動作を取り入れ、構造化されたパターンに形式化して保存することで、これらのテストを簡単に再実行できるようにします。手動でテストするのではなく、「適切な」ユニットテストケースを作成する場合、同じ時間、または経験したよりも少ない時間がかかり、何度でも繰り返すことができます。

私は何年もの間、コードの単体テストを書く必要があることを人々に納得させるよう努めてきました。彼らが最初にテストを作成したか（TDDのように）、または機能をコーディングした後でも、私は常に、コードの単体テストを持つことのすべての利点を説明しようとしました。ほとんど誰も私に反対しませんでした。あなたは明白な何かに反対することはできません、そしてどんな賢い人もユニットテストとTDDの利点を見るでしょう。

単体テストの問題は、動作の変更が必要であり、人々の動作を変更することが非常に難しいことです。言葉を使うと、多くの人があなたに同意するようになりますが、彼らが物事を行う方法に多くの変化は見られません。

あなたはそうすることによって人々を説得しなければなりません。あなたの個人的な成功は、あなたが持つかもしれないすべての議論よりも多くの人々を魅了するでしょう。あなたがユニットテストやTDDについて話しているだけでなく、あなたが説教していることをやっていて、あなたが成功していると彼らが見ると、人々はあなたを真似ようとします。

また、ユニットテストは最初は誰も作成しないため、主導的な役割を担う必要があります。そのため、その方法、方法、および使用可能なツールについて指導する必要がある場合があります。彼らが最初のテストを作成し、自分で作成したテストをレビューし、自分の経験から学んだトリック、イディオム、およびパターンを見せながら、彼らを助けます。しばらくすると、彼らは自分でメリットを見始め、ユニットテストまたはTDDをツールボックスに組み込むように動作を変更します。

変更は一晩で発生することはありませんが、少しの忍耐で目標を達成することができます。

テスト駆動型開発の主な部分は、よく見落とされがちですが、テスト可能なコードの作成です。最初はある種の妥協のように見えますが、テスト可能なコードも最終的にモジュール化され、保守可能で読み取り可能であることがわかります。それでも人々を説得する助けが必要な場合、これは単体テストの利点についての素晴らしく単純なプレゼンテーションです。

既存のコードベースが単体テストに適しておらず、すでに本番環境にある場合は、すべてのコードをリファクタリングして単体テストできるようにすることで解決するよりも多くの問題が発生する可能性があります。

代わりに、統合テストの改善に向けて努力する方がよいでしょう。単体テストなしで簡単に記述できるコードはたくさんあります。QAが要件ドキュメントに対して機能を検証できれば、完了です。それを出荷。

これの典型的な例は、GridViewにリンクされたASPXページに埋め込まれたSqlDataReaderです。コードはすべてASPXファイルにあります。SQLはストアドプロシージャ内にあります。あなたは何をユニットテストしますか？ページが想定されていることを実行する場合、自動化するものがあるように、ページをいくつかのレイヤーに本当に再設計する必要がありますか？

単体テストの最も優れた点の1つは、コードをテストするのが簡単になることです。テストなしで作成された既存のコードは、ユニットテストを目的としたものではないため、クラス間の高レベルの結合、クラス内のオブジェクトの設定が難しい（電子メールのような）ことは珍しくありません。サービス参照の送信-など。しかし、これであなたを失望させないでください！ユニットテストを書き始めると、全体的なコード設計が改善され、テストをすればするほど、アプリケーションの破損やバグの発生を恐れることなく、さらに多くの変更を加えることができるようになります。 。

コードを単体テストする理由はいくつかありますが、時間の経過とともに、テス​​トに費やす時間を節約することは、それを行う最良の理由の1つであることがわかります。提供したばかりのシステムでは、システムを手動でテストするよりもテストに多くの時間を費やすだろうという主張にもかかわらず、自動化された単体テストを実行することにしました。すべての単体テストが完了した後、10分未満で400を超えるテストケースを実行しました。コードに小さな変更を加える必要があるたびに、コードがバグなしで機能していることを確認するのに必要なのは10回だけでした。分。400以上のテストケースを手動で実行するのにかかる時間を想像できますか？

単体テストであれ、受け入れテストであれ、自動テストに関しては、手動で実行できることをコーディングするのは無駄な作業だと誰もが思っています。テストを1回だけ実行する場合は、それが当てはまる場合もあります。自動テストの最も優れた点は、手間をかけずに数回テストを実行できることです。2回目または3回目の実行後、無駄に費やした時間と労力はすでに支払われています。

最後のアドバイスは、コードを単体テストするだけでなく、最初にテストを開始することです（詳細については、TDDとBDDを参照してください）。

単体テストは、コードの一部をリファクタリングまたは再作成する場合にも特に役立ちます。単体テストの対象範囲が適切であれば、自信を持ってリファクタリングできます。単体テストがないと、何も壊していないことを確認するのが難しいことがよくあります。

要するに-はい。彼らはあらゆる努力の価値があります...ある程度まで。結局のところ、テストはコードであり、通常のコードの成長とよく似ていますが、テストを最終的にリファクタリングして、保守可能で持続可能なものにする必要があります。GOTCHASのトンがあります！単体テストに関しては、まあまあ、まあまあ、何も、そして何もしないということは、開発者が豊富な単体テストよりも自信を持って変更を行えるようにすることを意味します。

私は現在プロジェクトに取り組んでいます...それは多少TDDであり、ビジネスルールの大部分はテストとしてカプセル化されています...現在、約500程度のユニットテストがあります。この過去の反復では、データソースと、デスクトップアプリケーションがそのデータソースとどのようにインターフェースするかを改造する必要がありました。数日かかったが、その間ずっと、ユニットテストを実行して、何が壊れているのかを確認して修正した。変える; テストをビルドして実行します。あなたが破ったものを修正します。必要に応じて洗浄、すすぎ、繰り返します。従来、QAとボートの負荷に何日もかかっていたはずのことは、短くて楽しい経験でした。

前もって準備し、少し余分な努力をします。コア機能/機能をいじり始めなければならないときに、後で10倍の費用がかかります。

私はこの本を購入しました-これはxUnit Testingの知識の聖書です-おそらく私の棚で最も参照されている本の1つであり、毎日調べています： リンクテキスト

ときどき、私自身または同僚の1人が、わずかに不明瞭なバグの底に到達するまでに数時間を費やし、バグの原因が発見されたら、そのコードの単体テストが行​​われていない時間の90％を見つけます。開発者は時間を節約するために手抜きをしているため、単体テストは存在しませんが、これを失うことで、より多くのデバッグが可能になります。

単体テストの作成に少しの時間をかけるだけで、将来のデバッグにかかる​​時間を節約できます。

私は、十分に文書化されておらず、ひどい、大きなコードベースのメンテナンスエンジニアとして働いています。コードを書いた人たちがそのための単体テストを書いてくれたらいいのに。
変更を加えて製品コードを更新するたびに、なんらかの条件を考慮していないためにバグが発生するのではないかと怖いです。
彼らがテストを作成した場合、コードベースに変更を加えることはより簡単で高速になります（同時に、コードベースはより良い状態になります）。

ユニットテストは、何年も続く必要があり、元のコーダー以外の人が使用、変更、進化させる必要のあるAPIまたはフレームワークを作成するときに非常に役立つと思います。

ユニットテストは間違いなく努力する価値があります。残念ながら、実装するのが難しい（残念ながら一般的な）シナリオを選択しました。

ユニットテストの一番の利点は、それを最初から使用するときです。クラスを実装する前にユニットテストを作成できるほど幸運にも恵まれた、いくつかの選択された小さなプロジェクトで（インターフェイスは既にこれで完了しています）ポイント）。適切な単体テストを使用すると、クラスがまだ初期段階にあり、将来的に間違いなく統合される複雑なシステムの近くではないときに、クラスのバグを見つけて修正できます。

あなたのソフトウェアがしっかりとオブジェクト指向であるなら、あなたはそれほど多くの努力なしにクラスレベルでユニットテストを追加することができるはずです。あなたがそれほど幸運ではない場合でも、可能な限りユニットテストを組み込むようにしてください。新しい機能を追加するときは、新しい部分が明確なインターフェースで明確に定義されていることを確認してください。ユニットテストにより、作業がはるかに簡単になることがわかります。

「私たちのコードベースは簡単なテストに向いていない」と言ったとき、コードの匂いの最初の兆候です。ユニットテストの記述とは、コードをよりテストしやすくするために、通常、コードを別の方法で記述することを意味します。これは、私がテストを書かなければならないコードを書く際に長年にわたって見てきたものであり、より良い設計を行わざるを得なかったので、私の意見では良いことです。

私は知らない。多くの場所で単体テストが行​​われていませんが、コードの品質は良好です。マイクロソフトは単体テストを行いますが、ビルゲイツ氏はプレゼンテーションでブルースクリーンを表示しました。

このトピックについて非常に大きなブログ投稿を書きました。単体テストだけで作業する価値はなく、締め切りが近づくと通常はカットされます。

「テスト後」の検証の観点からユニットテストについて話すのではなく、実装の前にspec / test / ideaを記述することを決めたときに見つかった真の値を確認する必要があります。

この単純なアイデアにより、ソフトウェアの記述方法が変わり、「古い」方法に戻ることはできなくなりました。

テストの最初の開発が私の人生をどのように変えたか

はい-ユニットテストは間違いなく努力に値しますが、それが特効薬ではないことを知っておく必要があります。ユニットテストは機能しており、コードの変更に応じてテストを更新して関連性を保つように作業する必要がありますが、提供される値は、投入する努力に見合う価値があります。機能を常に検証できるため、免責なくリファクタリングできることは大きなメリットです。変更コードの後に​​テストを実行する。その秘訣は、テストしている作業単位や、テスト要件の足場に正確にこだわりすぎないようにすること、そして単体テストが実際に機能テストである場合などです。人々はこのことについて何時間も議論します。結局のところ、現実には、書き込みコードとして実行するテストは、実行しないよりも優れています。もう1つの公理は量ではなく質に関するものです-私は1000 'のコードベースを見てきました 残りの部分は特定のドメインのビジネスルールなどのドメイン固有の有用なものや実際には何もテストしないので、本質的に意味のないテストのs。30％のコードカバレッジを持つコードベースも見ましたが、テストは関連性があり、意味があり、コードのコア機能をテストし、コードの使用方法を表現していたため、本当に素晴らしいものでした。

新しいフレームワークまたはコードベースを探索するときに私のお気に入りのトリックの1つは、「それ」の単体テストを作成して、物事がどのように機能するかを発見することです。乾いたドキュメントを読むのではなく、何か新しいことをもっと学ぶには素晴らしい方法です:)

私は最近、職場でまったく同じ経験をしましたが、ほとんどの人が理論上のメリットを知っていましたが、具体的にそのメリットを売り込む必要があったので、私が使用したポイントは（成功した）です。

• 単一のプロセスでこれらすべてを実行できるため、予期しない入力（nullポインター、範囲外の値など）を処理するネガティブテストを実行するときに時間を節約できます。
• 変更の標準に関してコンパイル時に即座にフィードバックを提供します。
• これらは、通常の実行時に公開されない可能性のある内部データ表現をテストするのに役立ちます。

そして大きなもの...

• ユニットテストは必要ないかもしれませんが、誰かがやって来てコードを完全に理解せずに変更すると、彼らがするかもしれない愚かな間違いの多くを捕らえることができます。

私は数年前にTDDを発見し、それ以来、それを使用してすべてのペットプロジェクトを作成しました。プロジェクトをTDDするのにかかる時間は、カウボーイを一緒にするのと同じくらいの時間がかかると推定しましたが、完成品に対する自信が高まり、達成感を味わうことができなくなりました。

私はまた、それが私のデザインスタイルを改善するように感じます（物事を一緒にモックする必要がある場合に備えて、はるかにインターフェイス指向です）、そして上部の緑色の投稿が書いているように、それは「便秘のコーディング」に役立ちます：あなたが何を知らないとき次を書くために、またはあなたの前に困難な仕事があるなら、あなたは小さく書くことができます。

最後に、TDDの最も有用なアプリケーションはデバッグにあることがわかりました。これは、プロジェクトを作成してバグを再現可能な方法で生成できる問い合わせフレームワークをすでに開発している場合に限ります。

まだ誰も言及していないことの1つは、既存の自動テストを実際に実行および更新するというすべての開発者の取り組みを得るということです。新しい開発のために戻って壊れてしまった自動テストは、多くの価値を失い、自動テストを本当に苦痛にします。開発者がコードを手動でテストしたため、これらのテストのほとんどはバグを示していません。したがって、それらの更新に費やされた時間は無駄です。

懐疑論者が他の人がユニットテストで行っている作業を破壊しないように説得することは、テストから価値を得るのにはるかに重要であり、簡単かもしれません。

リポジトリから更新するたびに新機能が原因で壊れたテストの更新に何時間も費やすことは、生産的でも楽しいものでもありません。

NUnitを使用している場合、シンプルで効果的なデモの1つは、NUnit独自のテストスイートをその前で実行することです。コードベースにワークアウトを与える実際のテストスイートを見るのは、千の言葉に値します...

単体テストは、1人の開発者が頭で抱えているよりも大きなプロジェクトで多くのことを助けます。これにより、チェックイン前に単体テストスイートを実行して、何かが壊れていないかどうかを確認できます。ダウンこのカットたくさん座って、彼らがチェックインのバグを修正するために誰かを待っている、またはあなたはいくつかの仕事を成し遂げることができるように彼らの変更を元に戻すの面倒に行くながら親指をひねりしたのインスタンスで。また、リファクタリングにおいて非常に価値があるため、リファクタリングされたコードが元のコードが行ったすべてのテストに合格することを確認できます。

単体テストスイートを使用すると、残りの機能をそのままにしてコードを変更できます。その大きな利点です。新機能のコーディングが完了したら、ユニットテストスイートと回帰テストスイートを使用しますか。

ここで大多数とは反対の見方に同意します。 単体テストを記述しなくても問題ありません 特にプロトタイプが多いプログラミング（たとえばAI）は、単体テストと組み合わせることが困難です。