最近、ユニットテストよりも機能テストについて聞いたことがあります。
単体テストでは、特定のコードの可能性のそれぞれを、最も原子的な形式からテストすることを理解しています。しかし、機能テストはどうですか？
これは、コードが機能するかどうかをテストするだけのように聞こえますが、単体テストと同じくらい信頼できますか？
私はその問題について2つの考え方があると言われました。ユニットテストを好む人もいれば、機能テストを好む人もいます。
このテーマに関する私の道を説明し、啓蒙することができる良いリソース、リンク、本、参考文献、またはあなたの一人がいますか？
ありがとう！
単体テストと機能テストはではxorなく、andです。単体テストとは、ユニットを分離してテストすることですが、機能テストとは、統合して全体をテストすることです（すべてのユニットが正しく連携して動作しますか？）。
どちらも、優れたソフトウェアエンジニアリングプラクティスに必要なコンポーネントです。
ジェイソンの答えは正しいです。さまざまなタイプのテストにはさまざまな目的があり、最良の結果（優れた設計、仕様への適合、欠陥の削減）を得るために階層化することができます。
これらのカテゴリの間にはいくつかの重複があります。たとえば、単体テストで動作を指定できます。
そして他にもあります。ほとんどの人が知りたいと思っている以上のことについては、ソフトウェアテストを参照してください。
人々が見逃した1つのポイントは、単体テストはコードの断片を分離してテストすることです。たとえば、優れた単体テストはデータベースに影響を与えません。これには2つの利点があります。テストの実行が速くなるため、テストをより頻繁に実行できるようになります。また、緩く結合されたクラスを作成する必要があります（より優れた設計）。
あなたはリソースを求めました。RoyOsheroveの著書TheArtof Unit Testing with Examples in.NETをお勧めします。完璧な本はありませんが、これは良いテストを書くための多くの優れた指針を提供します。
編集：そして、既存のソフトウェアに対するテストを書くために、マイケル・フェザーズの本「レガシーコードで効果的に働く」に勝るものはありません。
単体テストでは、コードユニット（メソッドなど）をテストして、期待どおりに動作することを確認します。
機能テストでは、システム設計をテストして、部品が正しく相互作用することを確認します。文字列を受け取り、intして返し、それを完全にテストするコマンドを作成すると、それが機能することを確認できます。ただし、システムテストがない場合は、コードの残りの部分がnullを受け入れることができると考えているが、受け入れられないことに気付かない場合があります。
どちらのタイプのテストも重要です。
編集：gbjbaanbが言ったことにわずかに異なるビューを追加するには：
上記はすべて便利ですが、相互に排他的ではありません。あなたはそれらのほとんどを行うべきですが、あなたが各部分に費やす時間はあなたがそれらから得る結果に依存します、それだけです。コードがモジュール化されすぎて単体テストを簡単に行えない場合は、機能テストに力を注いでください。小さなコンポーネントのライブラリを作成している場合は、それらの単体テストに時間を費やしてください。軍用ミサイルの制御システムを作成している場合は、必ずサイトでそれらをテストする必要があります（失敗しても爆発するのは楽しいです:)）。
システムテストとも呼ばれる機能テストは、システム全体をテストし、機能要件が満たされていることを確認することを目的としています。
ユニットテストは、「ユニット」、つまりシステムが分離して構築されている機能またはメソッドをテストすることを目的としています。開発者テストと呼ばれることもあります。ユニットテストは事後に難しい場合があります。そのため、TDDはコードの前にテストを記述します。
これらは、ユニットがすべて一緒に統合された場合ではなく独立して動作できるため、またはユニットテストに合格し、すべての製品要件を満たしていないため、補完的です。
単体テストは、コードの一部をテストし、プログラマーに対して、別のコードが想定どおりに機能していることを確認します。テスト駆動開発では、コードが記述されてテストに合格する前に、単体テストが最初に記述され、失敗することが観察されます。プログラマーはユニットテストに興味があります。ユニットテストはすばやく実行できます。
機能テストは、ブラックボックスの要件をテストし、ユーザー機能の一部が整っていることを示します。たとえば、大きな赤いボタンを押すと、ベルが鳴り始めます。機能テストはコードをテストすることすらできないかもしれません。おそらく、ボタンを押すとベルが鳴る機械的なプロセスがあります。顧客は、理解できる方法で作業している場合、高レベルのプロセスを確認するため、機能テストに興味を持っています。多くの場合、実行に時間がかかります。
単体テストと機能テストには、2つの異なる結果があります。
単体テストは、小さなコードが期待どおりに機能することを確認します。これは通常、コードが正しく機能することを確認するために開発者によって行われます。それらは通常、テストフレームワークによっても自動化されます。
機能テストは、プログラムの特定の経路を通過することにより、機能が期待どおりに機能することを確認します。これらは通常、ソフトウェアの担当者によって実行され、プログラムがユーザーの想定どおりに機能することを保証します。それ自体、より高いレベルであるため、一度に複数のユニットをテストします。
どちらも重要だと思います。リソースが限られていて、テクニックを選択/選択する必要がある場合、それは作成する製品に依存すると思いますが、私が行うこと（いくつかのボタンを介して人間が使用する自動車制御製品）では、機能テストが最も重要です。これは、ユーザーが製品を入手したときに、本来の機能を実行することを確認します。これは、単体テストをオプトアウトする必要があるという意味ではありませんが、プッシュカムトゥショブの場合、優れたユーザーエクスペリエンスを確保し、製品をドアから出すには、機能が最も重要です。
たとえば、データベースエンジン（または必ずしもユーザー向けではない他の製品）を作成する場合、単体テストは実際に行うべきことかもしれません。
ほとんどの開発作業には両方の場所があります。
単体テストは、コードの小さな単位をテストして、それらが期待どおりに機能することを確認するためにあります。
機能テストは、システムの全体的な機能が期待どおりであることをテストするためにあります。
それらは異なるレベルにあり、両方を使用する必要があります。