機能テストが満たされている場合、ユニットテストは依然として重要ですか？短い概要について

Question

：

• 単体テストは右DEVのビューでそれを行うために何かを期待小さいものです。
• 機能テストは、機能テストが既に成立している場合は、物事がユーザーのビュー

に正しい、我々はまだユニットテストを実行する必要があります期待しているものがありますか？

ほとんどの場合（ウェブ開発をコンテキストとして使用します）、ブラウザーを使用して、他のユーザー/人にシステム/アプリケーションを試すことができるかどうかを確認するのが一般的です。

エッジケースのような他のテストをしましょう。

Answer 1

機能テストが「満足」しているかどうかを判断するために使用している指標はありますか？

私は、テストの種類を比較するためのベースラインを作成する客観的な測定をするのに役立つように感じます。共通のものはコードカバレッジです。

コードカバレッジを識別することで、機能テストと単体テストの比較が容易になりますが、機能テストは単体テストと同じコード行をカバーしていますか？それ以上の場合は冗長です。

• を実行する機能テストは、法外に長い：

  問題は、これは他の問題のトンを無視しているのですか？セットアップが難しいのですか、CIでのみ実行されていますか？次に、単体テストでコードの行を複製することは意味があります。これは、開発者に迅速なフィードバックを提供します。

• これはPOCプロジェクトですか、未熟なプロジェクトですか？機能テストは、より高いレベルのユースケースをアサートし、実装の詳細から抽象化できるようにすべきであるため、最良の結果をもたらす可能性があります。これは、実装の詳細が不確かな場合に非常に役立ちます。
• コードカバレッジは誤解を招きます.IO中心ライブラリ（DBドライバ）は、その依存関係をモックして100％のコードカバレッジを簡単に持つことができます。この場合、コードカバレッジを使用して機能テストとユニットテストを比較すると、機能テストでIO依存関係が実行されるため、複数のテストディメンションが欠落しています。 （この場合のIMOユニットテストは、実際にはかなり小さい値であり、IO重いコードに間違いを与えて、devの後のサイクルで通常発見される統合バグにつながります。
• あなたが触れた機能テストは、通常、クライアントのフローのいくつかを示します。機能テストを使用してすべてのエッジケースとエラー処理を実行することは、通常、リソースの浪費になりがちで、維持が難しい、スローテストの大きなスイートを作成する傾向があります。