スキルではなく数で相手を選ぶことにしたので、ここではテストを書くことがまだ価値があるという19の理由があります（時系列で）。 だからテスト
- 作成されたクラスのAPIを開発するのに役立ちます。 クラスのインターフェースを発明する代わりに、テストを書く過程でそれを開発します。
- アプリケーションアーキテクチャの開発を支援します。 少なくとも、これは低レベルのアーキテクチャであり、クラスが相互にやり取りする方法です。 経験が示すように、このようなアーキテクチャは、原則として、最も柔軟で経済的です。
- 特定のコードが現在機能しているかどうかを確認します。
- 変更が行われた後、特定のコードが機能するかどうかを確認します。
- 個々のクラスの機能を文書化します。
- システムの動作を文書化します（ユーザーの観点から）。
- まだ思いついていませんが、誰かが教えてくれるでしょうか？
テストがテストによって異なることは明らかであり、すべてのテストがそのような大きなメリットをもたらすわけではありません。 それを理解してみましょう。
コードの前または後にテストを作成しますか？
すべてが多かれ少なかれ明確です。 コードの後にテストを書くと、コードを書くのにテストを助けてくれる貴重な能力が失われます。 私の意見では、これはテストの最大の価値です。 ただし、ここでは内部のアーキテクトを閉じてテストを操縦する必要があるため、理解することも最も困難です。
2番目の重要なポイント：経験者が言うように、ほとんどの場合、後まで延期されるテストは書かれていないままです。
判定：コードの後にテストを書くのは、結果を本当に心配することなく、すぐにお金を削減する必要がある場合のみです。
どのコードをテストするのですか？
「どちらでも」ではなく、連続的なスペクトルがあります。つまり、1行の方法から、一連のユーザーアクションを含むシナリオ全体までです。 最初の極端はユニットテストと呼ばれ、2番目は受け入れテストであり、ギャップのどこかに統合テストがあります（誰かがより良い言葉を知っていますか？）そして、機能テスト、そして誰もがこれらの用語で異なることを理解しています。 ユニットテストは人々の間ではるかに人気があり、テスト駆動開発に関しては、デフォルトでユニットテストが意味されます。 第一に、彼らは書くのがはるかに簡単です-ある意味で、それはより少ないコードを必要とします、そして第二に、これは開発者が開発テストを書くのが好きであるという事実によるものです（それらについて）
ここで、そのようなテストとそのようなテストが、良いことのリストにどのように関係するかを見てみましょう。
単体テスト：
- 作成されたクラスのAPIを開発するのに役立ちます。
- アプリケーションアーキテクチャの開発を支援します。
- 特定のコードが現在機能しているかどうかを確認します。
- 変更が行われた後、特定のコードが機能するかどうかを確認します。
- 個々のクラスの機能を文書化します。
ご覧のように、非常に多くの利点がありますが、システム全体の正しい動作をチェックすること（少なくとも重要なこと）が1つ（最も重要）しかありません。 正常なニューロンのセットが病気の脳を作り出すことができるように、正しく機能するクラスのセットはシステムの正常な動作を保証しません。 クラス同士の相互作用をテストしても、単体テストでは、このクラスが特定の特定の信号を近隣に送信するという保証のみが提供されます。 しかし、これらの普遍的な調和の信号が必要かどうかは、単体テストではわかりません。
そして、ここで統合テストが助けになります。 書くのが難しい いくつかの部分で構成されるコンテキストを作成する必要があるため、保守がより困難になります。 テストがクラッシュした場合、どのコードを修正するかを判断するのに長い時間がかかるため、テストを上げることができ、他のコードが失敗することはありません。 ただし、特定の特定の条件下でシステムが正しく動作していることを確認できます。
統合テストは、アプリケーションの設計に役立ちますか？ それ自体ではなく、巨大なコードをチェックし、それ自体でこの部分を完全にいものにすることができます。 しかし、統合テストから始めて、リファクタリングの過程で、コードの個々のセクションにモジュラーテストを追加すると、本当に多くのメリットがもたらされます。
一般的に何をテストすべきですか？
ほとんどの開発者は、この質問に対して明白で、非常に率直に言って、非常に率直
Visual Studioには、このすべてを自動的に生成するチームさえ存在すると彼らは言います。
顧客、まあ、たとえばテスターに尋ねると、もう1つの非常に明白な答えがあります。システムの動作をテストします。 そこには仕様、またはユーザーストーリーがあり、それらを実行可能な形式で取得および書き換えます。 そして今、これは脳のための仕事です。多くの現在のこの神聖なプロセスがテスト駆動設計と呼ばれるようになるのは、そのようなテストを書く過程にあります。
最初のタイプのテストは開発と呼ばれることもあり、2番目のテストはカスタムです。 この分割を単体テストと統合テストに混同する傾向があります。 私はこれがそうではないことをすべての責任をもって宣言します。 テストメソッドの名前を変更して再配置するだけで、開発テストをユーザーテストに変えることができます。 典型的な例は検索です。 複数のパラメーターのデータを選択する1つのクラスを作成できます。 開発テストの場合、1つのテストクラスと多数のテストがあります。 スクリプトでクラスに分類します。名前、日付などで検索します。 カスタムテストを取得しました。 それらをどのように書いて整理するかは完全に明らかではありませんが、その利点は膨大です。 以下に加えて、冗長テストのないシステムが得られます。 これは、一部のテスト（機能ではなく、実装方法をテストするもの）が落ちることを恐れることなく、機能の実装を変更できることを意味します。
したがって、開発テスト：
- 作成されたクラスのAPIの開発には役立ちません。 結局のところ、すべてのクラスとメソッドをすでに思いついています。
- これらは、個々のメソッドのアーキテクチャと他のクラスとの相互作用を開発するのに役立ちます。
- 特定のコードが現在機能しているかどうかを確認します。
- 変更が行われた後、特定のコードが機能するかどうかを確認します。 ただし、システムが新しい要件で必要とするように機能するかどうかは明確ではありません。
- 個々のクラスの機能を文書化します。 ただし、多くの場合、これを理解するためには、メソッドコードに登る必要があります。
- システムの動作を文書化しないでください。
ユーザーテスト：
- 作成されたクラスのAPIを開発するのに役立ちます。
- アプリケーションアーキテクチャの開発を支援します。
- 特定のコードが現在機能しているかどうかを確認します。
- 変更が行われた後、特定のコードが機能するかどうかを確認します。
- 個々のクラスの機能は文書化されていません。
- システムの動作を文書化します。 同時に、テストの名前に基づいてシステムの動作が明確になるように、これらのテストを適切に編成することができます（コードを詳しく調べる必要はありません）。 テストの名前に基づいてドキュメントを自動的に生成するシステムもあります。
つまり、このクラスが何をするのかを理解したい場合は、クラス自体のコードを調べる必要があります。 その使用例を理解するために、開発テストのコードを見てみましょう。 しかし、システムがどのように役立つかを理解するために、ユーザーテストコードを見ていきます。
評決：私は常に開発テストを激しく無視してきたという事実にもかかわらず、特定の状況ではそれらが有用であると仮定する準備ができています。 しかし、私はまだカスタムのものを選択します。
最終的な考え
最終的なものは思いつかなかったので、すべてをそのままにしておきます。