通常、2種類の自動テストが使用されます。
単体テスト （製品の個々の部分、通常は個々の機能/方法のテスト）
機能テスト -特定の製品の機能をテストしますが、製品は単一の「ブラックボックス」として認識されます。
しかし、興味深い質問をしてみましょう-両方のタイプのテストがすぐに本当に必要ですか？そうでない場合、どちらがより重要ですか？
だから、初心者のために、ユニットテスト。
誰が書いていますか？ 原則として、モジュール/メソッド/関数の作成者。通常、この関数が何をしなければならないかを知っているのは彼だけです。 原則として、これは開発者であり、彼の目標はコードを単体テストでカバーすることです。 これは、おそらく、ユニットテストが非常に不完全であることを意味します（原則として、開発者はコードを「壊す」タスクがないため、正しいデータで作業を確認するか、誤ったデータの小さなセットを追加するだけです）。 、開発者が単体テストの作成プロセスに本当に責任がある場合、開発には2倍の時間がかかります。 信じられない？ しかし、「引数が数値であるかどうか」という関数の高品質なカバレッジのみでは、10回以上のチェックが必要です。 さらに、単体テストでは検証できない、または非常に困難な機能が膨大にあります（これらの機能はシステム全体の状態に依存する機能です）。
また、すべてのシステムモジュールが正しく動作しても、それらの正しい相互作用が保証されるわけではありません。
もう1つの点は、以前に使用したことのない製品に単体テストを導入する場合、これは非常に深刻な人件費であり、少数の機能をカバーするだけではまったく効果がありません。
最も重要なことは、すべての単体テストが正常に完了しても、製品の正しい動作を保証するものではありません：結局のところ、システムのさまざまな部分で同じ機能を使用できますが、単体テストは1つのユースケースにのみ目を向けて記述されています。
簡単な例：関数checkInt（a）{return/^►0-9†+$/ . test(a）}があるとします。 同時に、単体テストでは負の数のチェックはありません。 これはどういう意味ですか？ そして、特定の開発者がこの関数を次のように変更した場合
checkInt（a）{return/^-?[0-9†+$/.test(a）} 、ユニットテストは何も起こらなかったかのように合格します。 ただし、機能は破損します。 そして、エラーが検出されて修正された（関数が元の状態に戻る）後、機能の一部が別の場所に落ちます。 ユニットテストが常に正常に完了します。
私の練習では、機能を変更した後に失敗したため、ユニットテストにコメントするオプションもありました。
ただし、多くの開発者が使用するためのライブラリを作成する場合、ユニットテストは優れたツールであることを認識しておく必要があります。この場合、ユニットテストは関数のドキュメントの役割も果たします（関数の説明をスキップしてすぐに例を見るのは秘密ではありません使用）。 ただし、この場合、ライブラリ自体は製品であり、ユニットテストは機能テストと区別できません。
機能テストに戻りましょう。 原則として、それらはテスターによって書かれています。 間違いを見つけるタスクを持っている人（少なくともテスターにとって、私たちは常にそのようなタスクを設定します）。 そして、それは非標準データのチェックが増えることを意味します。 さらに、製品のアクセスコードとテストをアクセス権で共有できるため、「リリースする必要があるため、環境が緑になるように」テストを変更することを回避できます。
さらに、完成した製品をモジュールテストよりも機能テストでカバーする方がはるかに簡単です。これは、ユーザーインターフェイスの特定の部分がすべきこととすべきでないことを理解する方が、この関数が何をすべきかを判断するよりもはるかに簡単だからです。 そして最大の魅力-機能テストで製品の最も重要な部分のみをカバーし始めることができます-そして彼らは定期的にパフォーマンスを保証します。
まとめると。
機能テストは、製品のパフォーマンスを完全に決定します（少なくともそうすべきです）。 そして何よりも、顧客/開発マネージャーはそれを必要とします。 ユニットテストは、エラーをすばやく見つけたり、リファクタリングの結果を確認するために、開発者自身が主に必要とします。 したがって、優先順位は次のようになります。
- 機能テスト-必須
- 単体テスト-できれば、開発者の気分による