単体テストは努力する価値がありますか？
私は取り組んでいるチームの開発プロセスにユニットテストを統合することに取り組んでいます、そしていくつかの懐疑論者がいます。懐疑的な開発者にユニットテストの価値を説得するための良い方法は何ですか？私の特定のケースでは、機能やバグを修正しながらユニットテストを追加します。残念ながら、私たちのコードベースは簡単なテストには向いていません。
私たちのオフィスでは毎日次のようなやり取りがあります。
「男、私は単体テストが大好きです。何かがうまく動作するように一連の変更を加えることができただけで、テストをもう一度実行することで何も壊れていないことを確認できました。」
詳細は毎日変わりますが、感情は変わりません。単体テストとテスト駆動開発（TDD）には、非常に多くの隠された個人的な利点と明白な利点があります。
しかし、それを無視して、これが私の試みです。
ユニットテストを使用すると、コードに大きな変更をすばやく加えることができます。テストが実行されたため、テストが実行され、必要な変更を加えたら、テストを再度機能させる必要があるので、これでうまくいくことがわかります。これは時間を節約します。
TDDは、コーディングをいつ停止するかを理解するのに役立ちます。あなたのテストはあなたが今のところ十分に行ったことをあなたに確信を与え、そして微調整をやめて次のことに進むことができます。
テストとコードは連携してより良いコードを実現します。あなたのコードは悪い/バグがあるかもしれません。あなたのテストは悪い/バギーかもしれません。 TDDでは、 both が悪い、バグが少ないという可能性があります。多くの場合、修正が必要なテストですが、それでもまだ良い結果になります。
TDDはコーディングの便秘に役立ちます。テストを書く前に大きくて困難な作業に直面したとき、あなたは素早く動くでしょう。
ユニットテストは、作業しているコードの設計を実際に理解するのに役立ちます。何かをするためのコードを書く代わりに、あなたはあなたがコードを受けているすべての条件とそれからどんな期待される出力を概説することから始めます。
単体テストで即座に視覚的なフィードバックを得ることができます。とても満足です。また、中断後に中断した場所を拾うのもはるかに簡単です。
一般的な信念の単体テストとは反対に、2倍のコードを書いたり、コーディングを遅くしたりするわけではありません。いったんハングした後は、テストなしでコーディングするよりも速くて堅牢です。テストコード自体は通常比較的簡単であり、あなたがしていることに大きなオーバーヘッドを加えることはありません。これはあなたがやっているときだけ信じるものです:)
「頻繁に実行される不完全なテストは、まったく書かれていない完璧なテストよりもはるかに優れている」と言ったのはFowlerだと私は思う。私は、これが私のコードカバレッジの残りの部分がひどく不完全であってもテストが最も役に立つと思う場所でテストを書く許可を与えていると解釈します。
良いユニットテストは、何かするべきことを文書化し、定義するのに役立ちます。
単体テストはコードの再利用に役立ちます。自分のコード と の両方のテストを新しいプロジェクトに移行します。テストが再度実行されるまでコードを微調整します。
私が関わっている仕事の多くは単体テスト（Webアプリケーションのユーザーインタラクションなど）ではありませんが、それでも私たち全員がこのショップでテスト感染していて、テストが縛られたときは一番幸せです。私はそのアプローチをあまりお勧めできません。
単体テストはジムに行くのとよく似ています。あなたにとって良いことはわかっています。すべての議論が理にかなっているので、ワークアウトを開始します。最初のラッシュがありますが、それは素晴らしいことですが、数日後、あなたはそれがトラブルの価値があるかどうか疑問に思い始めます。服を着替えてハムスターホイールで走るのに1日かかっているのに、足と腕の痛み以外のものを本当に得ているかどうかはわかりません。
それから、たぶん1、2週間後、痛みがなくなると、ビッグデッドラインが近づき始めます。あなたは、「便利な」仕事を終わらせるために起きている時間ごとに費やす必要があるので、ジムに行くなどの余分なものを切り取ります。あなたは習慣から抜け出し、Big Deadlineが終わる頃には、あなたは元の状態に戻っています。なんとかジムに戻ったとしても、初めて行ったときと同じくらい痛いです。
あなたは何かを読んで、あなたが何か間違ったことをしているかどうかを確認します。あなたは、すべてのフィット感、運動の美徳を称賛する幸せな人々に対して少し不合理な悪意を感じ始めます。共通点はあまりないことに気づきます。ジムに行くために15分間運転する必要はありません。建物内に1つあります。彼らは運動の利点について誰かと議論する必要はありません。それは誰もがすることであり、重要であると受け入れるものです。大締め切りが近づくと、上司が食事をやめるように要求する以上に運動が不要であるとは言われません。
だから、あなたの質問に答えるには、単体テストは通常努力する価値がありますが、必要な努力の量は誰にとっても同じではありません。単体テストはあなたが実際にコード品質に価値のない会社のスパゲッティコードベースを扱っています。 （多くのマネージャーが単体テストの賞賛を歌いますが、それは重要なときにそれを固執するという意味ではありません。）
ユニットテストを仕事に取り入れようとしていて、期待していた太陽の光や虹がすべて見えない場合は、自分を責めないでください。ユニットテストを実際に機能させるには、新しい仕事を見つける必要があるかもしれません。
納得させるための最善の方法...バグを見つけ、それに対する単体テストを作成し、バグを修正する。
その特定のバグが二度と出現することはほとんどありません、そしてあなたはあなたのテストでそれを証明することができます。
あなたがこれを十分にやれば、他の人たちはすぐに追いつくでしょう。
thetalkingwalnutの質問：
単体テストの価値をチームの懐疑的な開発者に納得させる良い方法は何ですか？
ここにいる誰もが、なぜユニットテストが優れているのかを示す多くの理由を積み重ねようとしています。しかし、誰かに何かを納得させるための最良の方法は、多くの場合、引数をlistenにして、ポイントごとに対処することです。耳を傾けて彼らの懸念を言葉で表現するのを手伝うなら、あなたはそれぞれに対処し、おそらくあなたの視点に変換することができます（少なくとも、立ち上がらないようにしてください）。 だれが知っていますか？おそらく、ユニットテストがあなたの状況に適切でない理由を彼らはあなたに納得させるでしょう。ありそうもないが、可能です。おそらく、ユニットテストに対する引数を投稿する場合、反論を特定するのに役立ちます。
議論の両側に耳を傾け、理解することが重要です。人々の懸念に関係なく、あまりにも熱心に単体テストを採用しようとすると、宗教戦争に陥ることになります（そして、おそらく本当に価値のない単体テスト）。ゆっくりと採用し、最小のコストで最大の利益が得られる場所に適用することから始めれば、単体テストの価値を実証し、人々を説得する可能性が高くなります。これは思ったほど簡単ではないことを理解しています-通常、説得力のある議論を作成するには、ある程度の時間と慎重なメトリックが必要です。
単体テストは、他のツールと同様にツールであり、メリット（バグをキャッチする）がコスト（それらを作成する労力）を上回るように適用する必要があります。意味をなさない場合/それらを使用しないでください。また、それらはツールの備蓄の一部にすぎないことを忘れないでください（例：検査、アサーション、コードアナライザー、正式なメソッドなど）。私の開発者に伝えるのはこれです：
メソッドが必要ない理由（例：単純すぎて価値がある、または難しすぎて価値がない）やメソッドの検証方法（検査、アサーションなど）がある場合は、メソッドのテストの作成をスキップできます。 、正式な方法、インタラクティブ/統合テスト）。検査や正式な証明などの検証はある時点で行われ、その後生産コードが変更されるたびに繰り返す必要があることを考慮する必要がありますが、単体テストとアサーションは回帰テストとして使用できます（一度書かれて、その後繰り返し実行されます） ）。同意することもありますが、より頻繁に、メソッドが単純すぎて単体テストが難しいかどうかについて議論します。
開発者がメソッドが失敗するには単純すぎるように見えると主張する場合、単純な5行のユニットテストを作成するのに必要な60秒をかける価値はありませんか？これらの5行のコードは、翌年以降、毎晩実行されます（ナイトリービルドを行うのですか？）。たった一度でも識別に15分以上かかった可能性のある問題を見つけた場合、努力する価値があります。デバッグします。また、簡単な単体テストを作成すると、単体テストの数が増え、開発者の見栄えが良くなります。
一方、開発者がメソッドを単体テストするのが難しすぎると主張する場合（必要な多大な労力に値しない）、おそらくそれは、簡単な部分をテストするためにメソッドを分割またはリファクタリングする必要があることの良い兆候です。通常、これらは、シングルトン、現在時刻などの異常なリソース、またはデータベース結果セットなどの外部リソースに依存するメソッドです。通常、これらのメソッドは、リソースを取得するメソッド（getTime（）を呼び出すなど）と、リソースを引数として取得するメソッド（タイムスタンプをパラメーターとして取得するメソッド）にリファクタリングする必要があります。リソースを取得するメソッドのテストをスキップさせ、代わりにリソースを引数として取るメソッドの単体テストを作成します。通常、これにより、単体テストの作成がはるかに簡単になり、作成する価値があります。
開発者は、ユニットテストの包括性を「砂の中に線」で描く必要があります。後の開発では、バグを見つけるたびに、より包括的な単体テストで問題が検出されたかどうかを判断する必要があります。その場合、およびそのようなバグが繰り返し発生する場合は、将来のより包括的な単体テストの作成に向かって「行」を移動する必要があります（現在のバグの単体テストの追加または拡張から開始）。彼らは適切なバランスを見つける必要があります。
単体テストを実現することは重要なことではなく、特効薬ではありませんis単体テストが多すぎるということです。私の職場では、学んだ教訓を行うたびに、必然的に「ユニットテストをさらに書く必要がある」と聞きます。経営陣は、「ユニットテスト」==「良い」と頭に打ち込まれたため、うなずきます。
ただし、「より多くの単体テスト」の影響を理解する必要があります。開発者は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％）。
私のポイントは、ユニットテストが少なすぎると多すぎるとのバランスを理解していること、つまり本質的に問題の両側から考えてきたことを理解しなければならないということです。同僚や経営者にそのことを納得させることができれば、あなたは信頼を獲得し、おそらく彼らを勝ち取る可能性が高くなります。
私は単体テストを何度も試してきましたが、それでも私の状況を考えると努力する価値があると確信しています。
私はウェブサイトを開発していますが、そのロジックの大部分はデータベース内のデータの作成、取得または更新を含みます。私が単体テストの目的でデータベースを「モック」しようとしたとき、それは非常に面倒で、少し意味がないように見えました。
ビジネスロジックに関する単体テストを書いたとき、それは長い目で見ても本当に役に立ちませんでした。私は主にプロジェクトだけで作業しているので、私が作業しているものによってコードのどの部分が影響を受ける可能性があるか直観的に知る傾向があり、私はこれらの部分を手動でテストします。できるだけ早くクライアントにソリューションを提供したいのですが、単体テストは多くの場合時間の無駄になります。私は手動テストをリストアップし、それらを自分で見ていきます。
私は開発者のチームがプロジェクトに取り組んで互いのコードを更新するときに有益であるかもしれませんが、それでも私は開発者が高品質のものであるなら、よいコミュニケーションとよく書かれたコードは十分であるべき。
単体テストの優れた点の1つは、コードがどのように動作するように意図されているかを示すドキュメントとして機能することです。良いテストは一種のリファレンス実装のようなもので、チームメイトはそれらを見て自分のコードを自分のコードと統合する方法を見ることができます。
単体テストは初期投資の価値があります。数年前に単体テストを使用し始めてから、私はいくつかの本当の利点を見つけました：
- 回帰テスト コードに変更を加えることに対する恐怖を取り除きます（コードが変更されるたびに動作したり爆発したりするような暖かい輝きはありません）
- 実行可能コードの例 他のチームメンバーのために（そして6か月以内に自分自身のために..）
- 無慈悲 リファクタリング - これは信じられないほどやりがいのあることです。
コードスニペットは、テスト作成のオーバーヘッドを減らすのに非常に役立ちます。クラスのアウトラインとそれに関連する単体テストフィクスチャを数秒で作成できるようにするためのスニペットを作成することは難しくありません。
できるだけテストしないでください。
つまり、意図を明らかにするために十分な単体テストを作成する必要があります。これはよく理解されています。単体テストには費用がかかります。あなたが変更を加え、あなたがテストを変更しなければならないなら、あなたはそれほど敏捷ではないでしょう。単体テストを短くて甘いものにしてください。それから彼らは多くの価値を持っています。
決して壊れない、大きくて不器用で、多くの価値を提供しない、たくさんのテストを目にすることが多く、それらはあなたを遅くしてしまうだけです。
私は他の答えのどれにもこれを見ませんでした、しかし私が気づいた1つの事は 私はそんなに速くデバッグすることができた です。あなたが修正したコードにたどり着くための正しい一連のステップであなたのアプリをドリルダウンする必要はありません、あなたがブールエラーを犯したことを見つけるためにそしてそれをもう一度やる必要があるだけです。単体テストでは、デバッグしているコードに直接入ることができます。
[私は上の図を見れないようにするためのポイントがあります]
「みんなのユニットテスト、必ずしも気づいているわけではない - FACT」
考えてみましょう、あなたはおそらく文字列を解析して改行文字を削除する関数を書きます。初心者向けの開発者として、Main（）でそれを実装することでコマンドラインからそれをいくつかのケースで実行するか、ボタンで視覚的なフロントエンドを叩き、あなたの関数をいくつかのテキストボックスとボタンに結び付けて何が起こるのですか。
それは単体テストです - 基本的でひどくまとまっていますが、いくつかのケースでコードをテストします。
あなたはもっと複雑なものを書きます。 （単体テスト）いくつかのケースを通過してコードをデバッグしてトレースすると、エラーが発生します。あなたは、あなたがたどりながら値を見て、それらが正しいか間違っているかどうかを決定します。これはある程度の単体テストです。
ここでの単体テストでは、実際にその振る舞いを取り上げ、それを構造化パターンに定式化し、それを保存して、それらのテストを簡単に再実行できるようにしています。手動でテストするのではなく、「適切な」単体テストケースを作成すると、同じ時間、または経験を積むのと同じくらいの時間がかかり、何度も何度も繰り返すことができます。
何年もの間、私は彼らが自分たちのコードのためにユニットテストを書く必要があることを人々に納得させようとしました。彼らが最初に（TDDのように）テストを書いたかどうかにかかわらず、彼らが機能をコーディングした後に、私はいつもそれらにコードのためのユニットテストを持つことのすべての利点を説明しようとしました。誰も私に反対しませんでした。明白なことに異議を唱えることはできません。賢い人なら誰でも単体テストとTDDの利点を理解するでしょう。
単体テストの問題点は、動作の変更が必要であり、人々の動作を変更するのが非常に難しいということです。言葉で、あなたはあなたに同意する多くの人々を得るでしょう、しかしあなたは彼らが物事をする方法で多くの変化を見ることはないでしょう。
することによって人々を納得させる必要があります。あなたの個人的な成功はあなたが持っているかもしれないすべての議論より多くの人々を引き付けるでしょう。彼らがあなたが単体テストやTDDについて話しているのではなく、あなたが説教していることをやっていて成功しているのを見れば、人々はあなたを真似しようとします。
また、誰もが最初に単体テストを書くことはないので、主導的な役割を担う必要があります。そのためには、その方法や方法、使用可能なツールについて指導する必要があります。彼らが彼らの最初のテストを書いている間彼らを助けて、彼らが彼ら自身で書くテストを見直して、そして彼らにあなた自身の経験を通して学んだトリック、イディオムとパターンを見せてください。しばらくすると、彼らは自分で利点を見始め、単体テストまたはTDDをツールボックスに組み込むように動作を変更します。
変化は一晩で起こることはありませんが、少しの忍耐力で、あなたはあなたの目標を達成するかもしれません。
よく議論されるテスト駆動開発の主要部分は、テスト可能コードの作成です。最初はある種の妥協のように思えますが、テスト可能なコードも最終的にはモジュール式で保守可能で読み取り可能なものであることがわかります。あなたがまだ人々を納得させるのに助けが必要なら/ これ は単体テストの利点についての素晴らしいシンプルなプレゼンテーションです。
既存のコードベースが単体テストに向いておらず、すでに本番環境に入っている場合は、すべてのコードをリファクタリングして単体テスト可能にすることによって解決するよりも多くの問題を引き起こす可能性があります。
代わりに統合テストを改善するための努力をする方が得策かもしれません。単体テストを行わずに記述するのが簡単なコードがたくさんあります。QAが要件ドキュメントに対して機能を検証できるのであれば、完了です。それを出荷。
私の考えでは、この典型的な例は、GridViewにリンクされたASPXページに埋め込まれたSqlDataReaderです。コードはすべてASPXファイルにあります。 SQLはストアード・プロシージャー内にあります。あなたは何をユニットテストしますか？もしそのページがやるべきことをしているのなら、自動化するものがあるように本当にあなたはそれをいくつかの層に再設計するべきですか？
単体テストの最もよい点の1つは、コードをテストするとテストが簡単になることです。テストなしで作成された既存のコードは、単体テストを目的としたものではないため、クラス間の高度な結合レベル、クラス内の構成が困難なオブジェクト（電子メールのようなもの）は珍しくありません。サービス参照の送信 - などしかし、これはあなたをダウンさせないでください！単体テストを作成するにつれて全体的なコード設計が改善されることがわかります。テストするほど、アプリケーションを壊したりバグを発生させたりすることなく、より多くの変更を加えることに自信が持てるようになります。 。
コードをユニットテストするにはいくつかの理由がありますが、時間が経過するにつれて、テストにかかる時間がそれを実行するための最良の理由の1つであることがわかります。今配信したばかりのシステムでは、システムを手動でテストするよりもテストに時間がかかるという主張にもかかわらず、自動ユニットテストを実行することを主張しました。すべての単体テストを終えて、10分もかからずに400を超えるテストケースを実行しましたが、コードを少し変更する必要があるたびに、バグがなくてもコードがまだ機能していることを確認できました。分400以上のテストケースを手作業で実行するのにかかる時間を想像できますか？
自動テスト - 単体テストでも受け入れテストでも - 誰もが手動でできることをコーディングするのは無駄な努力だと考えていますが、テストを1回だけ実行する予定であれば真実であることもあります。自動テストの最大の利点は、何度も何度もテストを実行して実行できることです。2回目または3回目の実行後は、 浪費 の時間と労力がすでに支払われています。
最後のアドバイスは、コードを単体テストするだけでなく、最初にテストを開始することです（詳細は _ tdd _ および _ bdd _ を参照）。
単体テストは、断片のコードのリファクタリングや書き直しにも特に役立ちます。単体テストの適用範囲が広い場合は、自信を持ってリファクタリングできます。ユニットテストがなければ、何も壊さないようにするのは難しいことがよくあります。
私は、文書化されていない、ひどくて大きなコードベースのメンテナンスエンジニアとして働いています。コードを書いた人たちがそれのためにユニットテストを書いたことを願っています。
変更を加えて本番コードを更新するたびに、何らかの条件を考慮していないためにバグが生じる可能性があることを怖がっています。
彼らがテストを書いたならば、コードベースを変更することはより簡単でより速いでしょう（同時にコードベースはより良い状態になるでしょう）..
私は単体テストが何年にもわたって使用され、オリジナルのコーダ以外の人々によって使用され/変更され/発展させられなければならないAPIまたはフレームワークを書くとき非常に役に立つと思う。
一言で言えば - はい。彼らは努力のあらゆるオンスの価値があります...ある程度まで。テストは、結局のところまだコードであり、典型的なコードの成長と非常によく似ていますが、保守可能で持続可能であるためにはテストは最終的にリファクタリングされる必要があります。 GOTCHASのトンがあります！それが単体テストになると、しかし、ああああああああ、何もない、と私はNOTHINGが豊富な単体テストのセットよりも自信を持って変更を行うことを開発者に力を与えるという意味です。
私は今プロジェクトに取り組んでいます....それは多少TDDです、そして私達はテストとしてカプセル化された私達のビジネスルールの大部分を持っています...私達は今約500かそこらのユニットテストを持っています。この過去の反復で、データソースと、デスクトップアプリケーションがそのデータソースとどのように連動するかを見直す必要がありました。何日かかけて、壊れたものを確認して修正した単体テストを実行していました。変える;テストをビルドして実行します。あなたが壊したものを修正してください。洗浄、すすぎ、必要に応じて繰り返します。伝統的に何日ものQAとボートでのストレスがかかっていたことは、代わりに短くて楽しい経験でした。
前もって準備しておくと少し手間がかかりますが、コア機能を使い始める必要があるときには10倍の費用がかかります。
私はこの本を買った - それはxUnitテストの知識の聖書です - これはおそらく私の棚で最も参照されている本の一つです、そして私は毎日それを調べます： リンクテキスト
時折、私か私の同僚のどちらかが、わずかにあいまいなバグの根底にたどり着くまで数時間を費やし、バグの原因が判明した時点でコードが単体テストされていないことが90％あります。開発者は時間を節約するためにコーナーを切り開いているため、単体テストは存在しませんが、それからこれ以上のデバッグを失います。
単体テストを書くために少しの時間をかけることは将来のデバッグの時間を節約することができます。
「私たちのコードベースは簡単なテストには向いていません」と言ったとき、それはコードの匂いの最初の兆候です。単体テストの作成とは、コードをよりテストしやすくするために、通常、コードの作成方法を変えることです。これは私が自分のためにテストを書かなければならなかったコードを書くことで長年にわたって見たものとして私の考えでは良いことです、それは私がより良いデザインを出すことを余儀なくさせました。
私は知らない。多くの場所で単体テストは行われませんが、コードの品質は良好です。 Microsoftは単体テストを行いますが、Bill Gatesはプレゼンテーションでブルースクリーンを出しました。
単体テストは間違いなく努力する価値があります。残念ながら、それを実装するための難しい（残念ながら一般的な）シナリオを選択しました。
単体テストから得られる最大の利点は、最初からそれを使用するときです。クラスを実装する前に単体テストを書くことができた、いくつかの選択された小さなプロジェクトでは（インターフェイスはすでに完成しています）ポイント）。適切な単体テストを使用すると、まだ初期段階にあり、将来確実に統合されるような複雑なシステムの近くにはいない間に、クラスのバグを見つけて修正できます。
あなたのソフトウェアがしっかりとしたオブジェクト指向であるならば、あなたはあまり努力なしでクラスレベルで単体テストを追加することができるはずです。それほど幸運ではない場合でも、可能な限りユニットテストを組み込もうとするべきです。新しい機能を追加するときは、新しい部分が明確なインターフェースで明確に定義されていることを確認してください。単体テストで作業がはるかに簡単になります。
このトピックについて非常に大きなブログ記事を書いた。私は、単体テストだけでは作業に見合う価値がなく、通常締切が近づくとカットされることに気付きました。
「テスト後」の検証の観点から単体テストについて話す代わりに、実装の前にspec/test/ideaを書くことにしたときに見つけた真の値を見てください。
この単純な考えは私がソフトウェアを書く方法を変えました、そして、私は「古い」方法に戻らないでしょう。
まだ誰も言及していないことの1つは、すべての開発者が既存の自動テストを実際に実行して更新するというコミットメントを得ていることです。あなたが戻ってきて、新しい開発のために壊れていることがわかった自動テストは、多くの価値を失い、自動テストを本当に苦痛にします。開発者が手動でコードをテストしているので、これらのテストのほとんどはバグを示していないでしょう、それでそれらを更新するのに費やされる時間は単なる無駄です。
他の人がユニットテストで行っている作業を破壊しないように懐疑論を納得させることは、テストから価値を得るためにもっと重要であり、より簡単かもしれません。
リポジトリから更新するたびに新機能が原因で失敗したテストの更新に何時間も費やすのは、生産的でも楽しいものでもありません。
私は数年前にTDDを発見し、それ以来私のすべてのペットプロジェクトをそれを使って書いてきました。私は、TDDでプロジェクトをカウボーイでまとめるのとほぼ同じ時間がかかると見積もっていますが、最終製品への自信が高まり、達成感を得られないのです。
私はまたそれが私のデザインスタイルを改善していると感じます（物事を模擬する必要がある場合はもっとインターフェース指向です）。そして、一番上の緑色の記事が書いているように、次に書くために、またはあなたがあなたの前で困難な仕事をするならば、あなたは小さいと書くことができます。
最後に、TDDの最も有用なアプリケーションはデバッグにあることがわかります。これは、反復可能な方法でプロジェクトをプロデュースできる質問フレームワークをすでに開発しているからです。
はい - 単体テストは確かに努力する価値がありますが、あなたはそれが銀の弾丸ではないことを知っておくべきです。単体テストは機能し、コードの変更に合わせてテストを最新の状態に保ち、関連性を維持するために努力する必要がありますが、提供される価値は、努力してみる価値があります。変更コードの後にテストを実行することによって。トリックは、テストしている作業単位や、テスト要件をどのように足場にしているか、そしてユニットテストが実際に機能テストである場合などには、あまり時間がかからないようにすることです。結局のところ、現実には、あなたが自分の書いたコードとして行うテストは、実行しないよりも優れているということです。他の公理は量ではなく品質についてです - 私は残りが実際に特定のドメインのビジネスルールなどのような有用なものやドメイン固有のものをテストしないので本質的に無意味な1000のテストのコードベースを見ました。私は30％のコードカバレッジを持つコードベースを見ましたが、テストはそれが書かれたコードのコア機能性をテストし、そしてコードがどのように使われるべきかを表明したので意味があって意味があって本当に最高でした。
新しいフレームワークやコードベースを探索するときの私のお気に入りのトリックの1つは、物事がどのように機能するのかを発見するための「それ」のためのユニットテストを書くことです。ドライドキュメントを読むのではなく、新しいことについてもっと学ぶための素晴らしい方法です:)
私は最近私の職場でまったく同じ経験を経験しました、そしてそれらのほとんどが理論的な利益を知っていたが彼らに特に利益で売られなければならなかったので、ここで私は（首尾よく）使いました：
- これらすべてを1つのプロセスで実行できるので、予期しない入力（nullポインタ、範囲外の値など）を処理するネガティブテストを実行するときに時間を節約できます。
- それらは変更の標準に関してコンパイル時に即座のフィードバックを提供します。
- 通常の実行時には公開されない可能性がある内部データ表現をテストするのに役立ちます。
そして大きなもの...
- あなたは単体テストを必要としないかもしれませんが、他の誰かが完全に理解せずにコードを変更して修正するとき、それは彼らがするかもしれない愚かなミスの多くを捕らえることができます。
私の経験からすると、単体テストと統合テストは複雑なソフトウェア環境では「必須」です。
チームの開発者にユニットテストを書くように説得するために、開発環境にユニットテスト回帰分析を統合することを検討する必要があるかもしれません（例えば、毎日のビルドプロセスにおいて）。
単体テストが失敗した場合、問題を見つけるためにそれをデバッグするためにそれほど多くの時間を費やす必要がないことを開発者が知っていれば、それらを書くことがより奨励されるでしょう。
これがそのような機能を提供するツールです。
NUnitを使用している場合、単純だが効果的なデモは、それらの前でNUnit独自のテストスイートを実行することです。コードベースにトレーニングを与える本物のテストスイートを見ることは千語の価値があります...
単体テストに関して留意すべきことの1つは、開発者にとって快適なことです。
対照的に、機能テストはユーザー向けです。機能テストを追加するたびに、ユーザーに表示されるものをテストしていることになります。ユニットテストを追加すると、開発者としての生活が楽になります。その点ではちょっとした贅沢です。
ユニットを書くか機能テストを書くかを選択する必要があるときは、この二分法を念頭に置いてください。
私はここで大多数と反対の見方に同意します： 単体テストを書いてはいけません 特にプロトタイプ重視のプログラミング（例えばAI）は単体テストと組み合わせることは困難です。
単体テストは、開発者が頭で抱えることができるよりも大きいプロジェクトで大いに役立ちます。彼らはあなたがチェックインする前にユニットテストスイートを実行し、あなたが何かを壊したかどうかを発見することを可能にします。他の人がチェックインしたバグを修正するのを待っている間に親指を座っていじっていたり、変更を元に戻す手間がかかるので、 lot を減らすことができます。 。リファクタリングにおいても非常に貴重なので、リファクタリングされたコードが元のコードが行ったすべてのテストに合格することを確認できます。
単体テストスイートを使用すると、残りの機能をそのままにしながらコードを変更できます。それは大きな利点です。新機能のコーディングが終わったら、単体テストスイートと回帰テストスイートを使いますか。
単体テストのポイントは、テストを簡単にすることです。自動化されています。 「テストをしてください」これで完了です。あなたが直面している問題の1つがコードをテストするのが難しい場合、それが単体テストを使用するすべての中で最も良い理由です。
今日、私は以前に単体テストが書かれていたクラスを変更しなければなりませんでした。
テスト自体はよく書かれていて、私も考えていなかったテストシナリオが含まれていました。
幸運にもすべてのテストに合格し、私の変更はすぐに検証され、自信を持ってテスト環境に投入されました。
あなたが手動でソフトウェアをテストするとき、あなたは通常あなたが使うテスト/アクションの小さなセットを持っています。最終的には、既知の問題を回避できるように、入力データまたはアクションを自動的に変形します。単体テストは、物事が正しく機能しないことをあなたに思い出させるためにそこにあるべきです。
コードの前にテストを書くこと、メインコードの機能性を進化させるために新しいテスト/データを追加することをお勧めします。
物理学の学生として、私は実際に証明に非常に駆り立てられています。これを論理的に証明するか、実装が複雑になるにつれて難易度が劇的に増加するか、または適切なテストを通じて（可能な限り）経験的な機能の証明を行うことができます。
機能の論理的証拠を提供しない場合は、テストする必要があります。唯一の選択肢は、「コードは機能すると思います...」と言うことです。
@George Stocker "残念ながら私たちのコードベースは簡単なテストには向いていません。"単体テストには利点があることに誰もが同意しますが、このコードベースではコストが高いようです。費用が便益よりも大きいならば、なぜ彼らはそれに熱心であるべきですか？同僚に聞いてください。おそらく彼らにとって、単体テストの知覚される痛みは単体テストの知覚される価値よりも大きいです。
具体的には、できるだけ早く価値を得ようとすることで、気の利いた「xUnit is green」の値ではなく、ユーザーとメンテナが評価するコードをきれいにしてください。たぶん、あなたは1回の反復に対して単体テストを義務付け、それが努力の価値があるかどうかを議論しなければならないでしょう。
最初にテストすることは、単体テストに関連しないものにしてください。私は主にPerlで作業しているので、これらはPerl特有の例ですが、あなたは適応できます。
すべてのモジュールは正しくロードされコンパイルされていますか？ Perlでは、これはコードベースの各Foo.pmに対してFoo.tを作成することです。
use_ok( 'Foo' );すべてのPOD（Plain Ol 'Documentation）は正しくフォーマットされていますか？ Test :: Podを使用して、すべてのファイル内のすべてのPODのフォーマット設定の妥当性を検証します。
あなたは、これらが大きなことだとは思わないかもしれません、そして、そうではありません、しかし、私はあなたがいくらかの愚痴をつかむことを保証することができます。これらのテストが1時間に1回実行され、それが誰かの時期尚早なコミットをキャッチするとき、あなたは人々に「やあ、それはかなりクールだ」と言うでしょう。
単体テストの利点の1つは予測可能性です。
単体テストの前には、コードを作成するのにかかる時間はかなりの精度になると予測することができましたが、デバッグするのにどれくらいの時間がかかるかは予測できませんでした。
最近では、どのテストを作成するのかを計画できるので、コーディングにかかる時間がわかり、コーディングの最後にはシステムはすでにデバッグされています。これは開発プロセスに予測可能性をもたらし、それは多くのプレッシャーを取り除きますが、それでもすべての喜びを保ちます!!.
単体テストは、高品質コードに最も採用されている方法論の1つです。より安定した、独立した文書化されたコードへの貢献は十分に証明されています。単体テストコードはリポジトリの不可欠な部分と見なされて処理されるため、開発と保守が必要です。しかし、開発者は、単体テストにリソースが投資されても期待したほど成果が得られないという状況に遭遇することがよくあります。理想的な世界では、私たちがコーディングするすべてのメソッドは、そのコードをカバーし、その正当性を検証する一連のテストを持ちます。しかし、通常は時間的な制約のために、いくつかのテストをスキップするか、または質の悪いテストを書くかのいずれかです。そのような現実の中で、単体テストの開発と保守に費やされるリソースの量を念頭に置いている間、利用可能な時間を考えると、どのコードが最もテストに値するのかと自問しなければなりません。そして既存のテストから、どのテストが実際に維持して維持する価値があるのでしょうか。 こちら
単体テストは、全体的な開発コストを削減しながら、より少ないバグでソフトウェアをリリースするのに役立ちます。リンクをクリックすると、 ユニットテストの利点についての詳細を読むことができます
あなたは誰を説得しようとしていますか？エンジニアかマネージャー？あなたがあなたのエンジニアの同僚を納得させようとしているなら、私はあなたの最善の策は高品質のソフトウェアを作りたいという彼らの欲求に訴えることであると思います。それがバグを見つけることを示す多くの研究があります、そして、彼らが良い仕事をすることに関心があるならば、それはそれらにとって十分であるべきです。
あなたが管理を納得させようとしているならば、あなたはおそらく検出されないであろう欠陥のコストがテストを書くコストよりも大きいと言ってある種のコスト/利益推論をしなければならないでしょう。顧客の信頼の喪失など、無理な費用も含めるようにしてください。