単体テストを行わないのはいつが適切ですか？

私は小さな会社でソロ開発者として働いています。私は実際に会社で唯一の開発者です。定期的に書いて保守しているいくつかの（比較的）大規模なプロジェクトがあり、それらをサポートするテストはありません。新しいプロジェクトを始めるとき、TDDアプローチを試してみるべきかどうかとよく疑問に思います。それは良いアイデアのように聞こえますが、私は正直に関係する余分な仕事を正当化することはできません。

私は自分のデザインを前向きに考えようと努力しています。いつか別の開発者がコードを保守するか、少なくともトラブルシューティングを行う必要があることは確かです。できる限りシンプルなものにし、把握するのが難しいものをコメントして文書化します。そして実際、これらのプロジェクトはそれほど大きくも複雑でもないので、まともな開発者は理解するのに苦労するでしょう。

私が見たテストの例の多くは、コードのすべての面をカバーする詳細にまで及びます。私が唯一の開発者であり、プロジェクト全体のコードに非常に近いので、手動で書き込みをテストするパターンに従う方がはるかに効率的です。また、要件や機能は頻繁に変更されるため、テストを維持するとプロジェクトにかなりの量のドラッグが追加されます。そうでなければビジネスニーズの解決に費やすことができる時間。

そのため、毎回同じ結論に達します。投資収益率が低すぎます。

私は時折、雇用日に基づいて誰かが会社にいた年数を計算するなど、アルゴリズムを正しく記述したことを確認するために、いくつかのテストを設定しました。しかし、コードカバレッジの観点からは、コードの約1％をカバーしています。

私の状況では、ユニットテストを定期的に行う方法をまだ見つけることができますか、それともそのオーバーヘッドを回避することを正当化できますか？

更新： 除外した私の状況に関するいくつかのこと：私のプロジェクトはすべてWebアプリケーションです。すべてのコードをカバーするには、自動化されたUIテストを使用する必要がありますが、それは手動テストよりも大きなメリットが見られない領域です。

私が見たテストの例の多くは、コードのすべての面をカバーする詳細にまで及びます。

そう？すべてをテストする必要はありません。関連するものだけ。

私が唯一の開発者であり、プロジェクト全体のコードに非常に近いので、手動で書き込みをテストするパターンに従う方がはるかに効率的です。

それは実際には間違っています。より効率的ではありません。それは本当にただの習慣です。

他のソロ開発者は、スケッチまたはアウトラインを作成し、テストケースを作成してから、アウトラインに最終コードを入力します。

それは非常に効率的です。

また、要件や機能は頻繁に変更されるため、テストを維持するとプロジェクトにかなりの量のドラッグが追加されます。

それも間違っています。テストはドラッグではありません。要件の変更はドラッグです。

要件を反映するようにテストを修正する必要があります。それらの特徴点、または高レベル; 最初に書き込まれるか、最後に書き込まれます。

テストに合格するまで、コードは実行されません。それがソフトウェアの唯一の普遍的な真実です。

限定的な「ここにある」受け入れテストを行うことができます。

または、いくつかの単体テストを使用できます。

または、両方を持つことができます。

しかし、あなたが何をしても、ソフトウェアが機能することを実証するテストは常にあります。

少し形式的で素晴らしき単体テストツールスイートがあれば、そのテストははるかに便利になると思います。

瞬きで実行でき、緑または赤のライトが点灯する一連のテストがあると想像してください。この一連のテストがすべてをテストしたと想像してください！テストスイートを実行するために必要な作業は、^ Tと入力するだけであったと想像してください。これはあなたにどんな力を与えますか？

何かを壊すことを恐れずにコードを変更できますか？古い機能を壊すことを恐れずに新しい機能を追加できますか？損傷を恐れずに、乱雑なコードをすばやくクリーンアップできますか？

はい、それらすべてを行うことができます！そして、時間の経過とともにコードはどうなりますか？それをきれいにするリスクがないので、それはますますきれいになります。

肩に小さな妖精がいると想像しましょう。あなたがコード行を書くたびに、妖精はテストスイートに何かを追加し、そのコード行が意図したとおりに動作することをテストします。そのため、数秒ごとに^ Tを押して、書いたコードの最後の行が機能したことを確認できます。

どのくらいのデバッグを行うと思いますか？

これが幻想のように聞こえるなら、あなたは正しい。しかし、現実はそれほど変わりません。まばたきを数秒で、妖精をTDDの規律で置き換えれば、ほぼ完成です。

1年前に構築したシステムに戻ってきて、中心オブジェクトの1つを作成する方法を忘れたとしましょう。そのオブジェクトを作成できるあらゆる方法で作成するテストがあります。これらのテストを読んで、記憶をジョギングできます。APIを呼び出す必要がありますか？呼び出し可能なすべての方法でそのAPIを呼び出すテストがあります。これらのテストは、理解できる言語で書かれた小さなドキュメントです。それらは完全に明確です。それらは非常に形式的であるため、実行されます。そして、彼らはアプリケーションと同期を取ることができません！

投資する価値がない？あなたは私をからかっていなければならない！誰もそのテストスイートを望まないでしょうか？自分に賛成して、愚かなことを口論するのをやめてください。TDDを上手に行う方法を学び、どれだけ速くなるか、コードがどれだけきれいになるかを見てください。

あなたが犯している間違いは、テストが時間的な投資であり、即座に利益をもたらさないことです。必ずしもそのように機能するとは限りません。

最初にテストを書くことは、コードのこの部分が何をする必要があるかに本当に焦点を合わせます。

次に、それらを実行すると、テストで発生するバグが明らかになります。

第三に、それらを実行すると、テストでは発生しなかったバグが表示されることがあり、実稼働環境で実際にあなたに噛みついてしまいます。

第4に、実行中のシステムでバグに遭遇し、そのための単体テストを作成した場合、そのバグを後で再導入することはできません。それは本当に大きな助けになります。再導入されたバグは一般的で非常に迷惑です。

第5に、コードを他の人に引き渡す必要がある場合、テストスイートを使用することで作業がはるかに容易になります。また、プロジェクトを無視して数年後にプロジェクトに戻ってきた場合、そのプロジェクトにそれほど近づかず、あなたにとっても役立つでしょう。

私の経験では、プロジェクトの開発全体を通して、適切な単体テストを行うことで、プロセスが常により速く、より信頼できるものになりました。

JUnit（Javaユニットテストフレームワーク）のスタッフは、テストするのが簡単すぎる場合はテストしないという哲学を持っています。かなり実用的であるため、Best Practices FAQを読むことを強くお勧めします。

TDDは、ソフトウェアを記述する別のプロセスです。単体テストの背後にある基本的な前提は、デバッガーがコードをステップ実行する時間を短縮し、コードの変更がシステムの他の何かを誤って壊しているかどうかをより迅速に把握することです。TDDに適合します。TDDサイクルは次のとおりです。

1. テストを書く
2. 失敗するのを見てください（何かする必要があることを証明してください）
3. テストに合格するために必要なものだけを記述してください。
4. それが通過するのを見てください（はい！）
5. リファクタリング（改善する）
6. 洗浄、すすぎ、繰り返し

TDDを適用することについてそれほど明白ではないのは、コードの記述方法が変わることです。コードが機能していることをテスト/検証する方法について考えるように強制することにより、テスト可能なコードを記述しています。また、ユニットテストについて話しているため、通常はコードがよりモジュール化されることを意味します。私にとって、モジュール式でテスト可能なコードは前もって大きな勝利です。

ここで、C＃プロパティなどをテストする必要がありますか？次のように定義されたプロパティを想像してください：

bool IsWorthTesting {get; set;}

この時点で言語機能をテストしているため、答えは「いいえ」で、テストする価値はありません。C＃プラットフォームの人たちがそれを正しく実現したと信じてください。また、失敗した場合、それを修正するにはどうすればよいですか？

また、適切にテストするには非常に手間がかかりすぎるコードの特定の部分があることがわかります。それは、それをしないことを意味しますが、トリッキーな問題によって使用される/使用されるコードを必ずテストしてください。

• インストールが失敗した場合にのみ発生する可能性のあるチェックされた例外。Javaにはこれらがたくさんあります。インストールされたファイルをハッキングせずに失敗する方法がない場合でも、catchブロックを記述するか、チェック済み例外を宣言する必要があります。
• ユーザーインターフェイス。テスト対象のコントロールを見つけ、適切なイベントを呼び出してユーザーのアクションをシミュレートするのは非常に面倒であり、場合によっては不可能です。ただし、Model / View / Controllerパターンを使用する場合は、モデルとコントローラーがテストされていることを確認し、ビュー部分を手動テストに任せることができます。
• クライアント/サーバーの相互作用。これはもはや単体テストではなく、統合テストになりました。回線を介してメッセージを送受信するまでのすべての部分を記述しますが、実際には回線を経由しないでください。良いアプローチは、実際の通信で生の通信と通信するコードの責任を減らすことです。ユニットテストコードで、通信オブジェクトをモックアウトして、サービスが期待どおりに動作することを確認します。

信じられないかもしれませんが、TDDは、開発の持続可能なペースへの移行を支援します。それは魔法によるものではなく、タイトなフィードバックループがあり、本当に愚かな間違いをすばやくキャッチできるからです。これらの間違いを修正するコストは基本的に一定です（少なくとも計画の目的には十分です）。小さな間違いは決して大きな間違いには成長しないからです。それを、コードの大暴れ/デバッグパージスプリントのバースト性と比較してください。

テストのコストとバグのコストのバランスを取る必要があります。

失敗が「ファイルが見つかりません」であるファイルを開く関数の10行の単体テストを書くことは無意味です。

複雑なデータ構造に対して複雑なことを行う関数-明らかにそうです。

トリッキーなビットは中間にあります。ただし、単体テストの真の価値は特定の機能をテストすることではなく、それらの間の扱いにくい相互作用をテストすることであることを忘れないでください。そのため、1ビットのコードの変更が、1000行離れた別のモジュールの一部の機能を破壊することを発見する単体テストは、コーヒーの中でその価値があります。

テストはギャンブルです。

テストの作成は、ユニットで発生し、そのテストでバグをキャッチしない（現在および将来のすべてのコード改訂中）バグのコストが、テストの開発コストよりも大きいという賭けです。これらのテスト開発コストには、追加されたテストエンジニアリングの給与、市場投入までの時間の追加、他のものをコーディングしないことによる機会損失の損失などが含まれます。

他の賭けと同様に、時には勝ち、時には負けます。

バグがはるかに少ない最近のソフトウェアは、最初に市場に出回る迅速だがバグのあるものに勝ちます。時には反対。特定の分野の統計情報と、経営陣がギャンブルしたい金額を確認する必要があります。

いくつかの種類のバグは、統計的には追加の特定のテストを作成する価値がないほど、作成される可能性が非常に低いか、初期の健全性テストから除外される可能性があります。ただし、バグのコストが非常に大きい場合（医療、核など）、企業は負けた賭けをしなければなりません（保険の購入と同様）。多くのアプリはそのような高い失敗コストを持たないため、より高い不経済な保険の適用範囲を必要としません。他の人がします。

私のアドバイスは、適切に動作させたいコードのみをテストすることです。

バグを残し、将来的に問題を引き起こすコードをテストしないでください。

TDDアプローチを試すべきかどうかよく疑問に思います。それは良いアイデアのように聞こえますが、私は正直に関係する余分な仕事を正当化することはできません。

TDDと単体テストは同じものではありません。

コードを記述して、後で単体テストを追加できます。これはTDDではなく、多くの余分な作業です。

TDDは、赤信号のループでコーディングする方法です。緑の光。繰り返しをリファクタリングします。

これは、まだ存在しないコードのテストを作成し、テストが失敗するのを見て、コードを修正してテストが機能するようにし、コードを「正しく」することを意味します。多くの場合、これにより作業が節約されます

TDDの利点の1つは、トリビアについて考える必要が減ることです。オフバイワンエラーのようなものは消えます。APIドキュメントを検索して、返されるリストが0または1で始まるかどうかを調べる必要はありません。

ほとんどすべてをテストするシステムで作業しました。テストの注目すべき実行は、PDFおよびXLS出力コードでした。

どうして？データを収集し、出力の作成に使用されるモデルを構築した部分をテストすることができました。また、モデルのどの部分がPDFファイルに保存されるかを把握する部分をテストすることもできました。それは完全に主観的であるため、PDFが正常に見えるかどうかをテストすることはできませんでした。PDFのすべての部分が一般的なユーザーにとって読み取り可能であることをテストすることはできませんでした。これも主観的だからです。または、棒グラフと円グラフの選択がデータセットに対して正しい場合。

出力が主観的である場合、努力する価値があることを実行できるユニットテストはほとんどありません。

多くの場合、「手動での書き込みテスト」は、いくつかのテストを書くよりも時間がかかりません。これらのテストをいつでも再実行できるため、時間を節約できます。

あなたのテスト（コードカバレッジと混同すべきではない）といくつかのまともな機能カバレッジを持っている場合、そしてあなたは10個の機能を持っているとしましょう-ボタンをクリックすると、あなたは、およそ10持っていることを意味：考えあんた再やってテストを...座ってコーヒーを飲みながら。

あなたもしていない持って minutaeをテストします。細かい点まで踏み込みたくない場合は、機能をカバーする統合テストを作成できます... IMO、一部の単体テストでは、コードではなく言語とプラットフォームのテストがきめ細かすぎます。

TL; DRメリットがあまりにも優れているため、実際には適切ではありません。

私が出会った2つの非常に良い答えはここにあります：

1. 単体テストと手動テストのタイミング
2. 単体テストに関しては何をテストしないのですか？

知覚されるオーバーヘッドを回避する理由：

• あなたの会社のための即時時間/コスト節約
• あなたがいなくなった後でも、長期的にはトラブルシューティング/保守性/拡張の潜在的な時間/コストの節約。

あなたの仕事の質の証明としてあなたの側から素晴らしい製品を残したくないですか？利己的な言葉で言えば、あなたがするのはあなたにとって良いことではありませんか？

長期的には時間を節約できるため、プロの開発者は単体テストを作成します。遅かれ早かれコードをテストし、ユーザーがそうしないと、後でバグを修正する必要がある場合、修正が難しくなり、ノックオン効果が増えます。

テストなしでコードを記述していて、バグがない場合は問題ありません。ただし、バグがゼロではない重要なシステムを作成できるとは思わないので、何らかの方法でテストしていると思います。

ユニットテストは、古いコードを変更またはリファクタリングする際の回帰を防ぐためにも重要です。彼らはあなたの変更が古いコードを壊していないことを証明しませんが、彼らはあなたに多くの自信を与えます（もちろん彼らが合格する限り:)）

戻ってきて、既に出荷したコードのテストのバッチ全体を書くことはしませんが、次回機能を変更する必要があるときは、そのモジュールまたはクラスのテストを書くことをお勧めします。 +変更を適​​用する前。それがあなたを助けるかどうか見てください。

あなたがそれを試して、正直に言ってそれは十分に公平であると言うことができますが、アプローチを試用している間に少なくともあなたの価値があるようにするのに役立つ十分な業界証拠があると思います。

質問はTDDについてではなく、一般的な単体テストについてであるにもかかわらず、ほとんどの回答はpro-TDDのようです。

単体テストを行うか、単体テストを行わないかの背後には、完全に客観的なルールはありません。しかし、多くのプログラマーが単体テストを行わないと思われることが何度かあります。

1. プライベートメソッド

OOPの哲学によっては、プライベートメソッドを作成して、パブリックメソッドから複雑なルーチンを分離する場合があります。パブリックメソッドは通常、さまざまな場所で呼び出され、頻繁に使用されることを意図しています。プライベートメソッドは、クラスまたはモジュール内の1つまたは2つのパブリックメソッドによって、非常に具体的な目的でのみ実際に呼び出されます。通常、パブリックメソッドの単体テストを作成するだけで十分ですが、マジックの一部を実現する基礎となるプライベートメソッドを作成することはできません。プライベートメソッドで何か問題が発生した場合は、パブリックメソッドの単体テストでこれらの問題を検出することができます。

2. 既に動作していることがわかっているもの（または他の人がテストしたもの）

多くの新しいプログラマーは、最初にテストすることを学んでいるときにこれに反対し、実行されているすべての行をテストする必要があると考えています。外部ライブラリを使用しており、その機能が作成者によって十分にテストされ、文書化されている場合、通常、単体テストで特定の機能をテストすることは無意味です。たとえば、誰かがActiveRecordモデルがデータベースへの「before_save」コールバックで属性の正しい値を保持することを確認するテストを書くかもしれません。おそらくコールバックが呼び出しているメソッドですが、コールバックの動作自体ではありません。インポートされたライブラリの根本的な問題は、単体テストではなく、受け入れテストを通じて明らかにする必要があります。

これらの両方は、TDDを行っているかどうかに関係なく適用できます。

ケンと私とそこにいる他の多くの開発者は、私たちのキャリアを通じて何度もあなたと同じ結論に達しました。

他の多くの人がそうであるように、あなたが見つけるだろうと思う真実は、アプリケーションのテストを書く最初の投資は気が遠くなるように見えるかもしれませんが、うまく書いてコードの正しい部分をターゲットにすれば、本当に節約できます時間の。

私の大きな問題は、利用可能なテストフレームワークにありました。それらが私が探しているものであると本当に感じたことがなかったので、私は自分自身の非常にシンプルなソリューションを展開しました。回帰テストの「ダークサイド」に私を連れて行くのは本当に助けになりました。ここでやったことの基本的なスニペットを共有します。うまくいけば、あなたに合った解決策を見つけることができます。

public interface ITest {
    public string Name {
        get;
    }
    public string Description {
        get;
    }
    public List<ITest> SubTests {
        get;
    }
    public TestResult Execute();
}

public class TestResult {
    public bool Succesful {
        get;
        set;
    }

    public string ResultMessage {
        get;
        set;
    }

    private Dictionary<ITest, TestResult> subTestResults = new Dictionary<ITest, TestResult>();
    public Dictionary<ITest, TestResult> SubTestResults {
        get {
            return subTestResults;
        }
        set {
            subTestResults = value;
        }
    }
}

その後の唯一のトリッキーな部分は、あなたがしているどんなプロジェクトに対しても、あなたがどの程度の粒度レベルが最高の「費用対効果」だと思うかを把握することです。

アドレス帳を作成するには、エンタープライズ検索エンジンよりもテストが少なくて済みますが、基本は実際には変わりません。

幸運を！