私が最終的に参加するほとんどのギグでは、単体テストがほとんどまたはまったくありません。通常、単体テストと呼ばれるものは実際には統合テストであり、開発者のマシンから実行されることはめったにありません。私は通常、この 2 つの違いを説教することから伝道を開始し、人々に非常に焦点を絞った単体テストを作成してもらい、統合テストは後で任せるようにします。つまり、十分な数の人が単体テストを作成し、統合の作成に「進む」ことができるようになったときです。テスト。受け入れまたはシステム レベルのテストは、通常、開発者によって手動で処理され、次に QA 部門によって処理されます。
私の質問は、アジャイル環境の外で作業する場合、単体テスト、統合テスト、および受け入れテストにどれだけの労力を費やしていますか?また、何から最も価値があると思いますか?
私は最初から単体テストを叩こうとしています。私は世界最大の TDD ファンというわけではありませんが、単体テストには熱心です。すべての単体テストが機能するため、魔法の妖精が統合テストを見事にパスすることを保証するとは思いませんが、かなり近いものになっています。
受け入れテストに関しては、単体テストが成功する (または、失敗すると思われる場合は失敗する) ことがわかるまで、何かを見ようとさえしません。単体テストがまったくないことを受け入れるケースはあまり思いつきません。アプリケーションの一部のコア ライブラリが更新された場合はどうなりますか?
多くの人は、単体テストは開発者中心であると主張しますが、それは正しいでしょう。ただし、単体テストの欠如は、それ自体がすべての指標です..特に受け入れテストを行っている人がたまたま開発者である場合:)
編集：
統合テストも私にとって重要です。私たちは通常、非常に厳しい仕様に基づいて構築します..統合テストが失敗した場合 (以前に合格した後)、それはスコープ クリープの強力な指標です。それが起こった場合、それを修正する前に誰かが騒ぐ必要があります.
多くの場合、この質問に対する答えは極端になります。カバレッジがほぼ 100% であるか、単体テストがばかげているかのように....
バランスを見つける必要があると思います。
クラスのロジックが失敗する可能性があるという合理的な疑いがある場合は、単体テストを使用してください。単体テストは分離されたクラスで実行する必要があるため、クラスが使用するサービスをモックする必要がある可能性があります。これにより、単体テストによってクラスが期待どおりに機能することが保証されるため、安全にリファクタリングを実行できます。
アプリケーションが完全に機能することを確認するには、統合テストが必要です。多数の単体テストを行うことができますが、アプリケーションが正しく動作するという意味ではありません。
受け入れテストに関しては、あなたに完全に同意します。それらは（スプリントの）最後に行い、部分的に手動で行う必要があります。
単体テストは壁の個々のレンガをテストするようなものであり、機能/統合テストは壁全体の安定性をテストするようなものだという比較を聞きました。
単体テストは、開発者がクラスが想定どおりに動作していることを確認するために必要です。
機能/統合テストは、特定の機能を実際に提供するという「全体像」の目標を見逃していないことを確認するために必要です。
したがって、どちらも絶対に必要であり、ROI の観点からは、どちらかを除外するのは得策ではありません。
混同できないと思います。説明した各テストには、異なるターゲットがあります。
単体テストは開発者を対象としています。モジュールの実装前または実装と並行して単体テストを作成し、モジュールが機能するか、すべてのインターフェイスと要件が満たされていることを確認します。
テストセンターから開発後、統合テストを行います。開発中の単体テストのように、単一のモジュールをテストすることはありません。統合テストは、複数のモジュール間の相互作用をカバーしています。
多くの場合、受け入れテストでは、すべての要件が満たされ、機能が指定どおりに実装されているかどうかを確認するために、顧客自身が関与します。