冗長コードにつながる機能テストと受け入れテスト
私が知っているのは：
- 機能テストは開発者の視点から単一のコンポーネント（WebAppのコントローラーなど）をテストすることを目的としています。 =>うまく機能させるためにすべての要件を満たしましたか？
- 受け入れテストは、コンポーネントのグループを一緒にテストすることを目的としており、ビジネスの観点に焦点を当てています。 =>プログラムはクライアント/ビジネス/顧客から提供された要件を満たしていますか？
今日、私は個人的なプロジェクトに取り組んでおり、BDD /テスト方法に従って、受け入れテストと機能テストを作成し始めました。
機能テストの多くの要件が、受け入れテストに必要な要件とまったく同じであることに気づきました。
Eコマースのバスケットに商品を追加することを目的としたwebappコントローラーがあるとします。
関連する機能テストの1つは次のとおりです。
productList.htmlページに移動してaddProductToBasketアクションを呼び出すと、コントローラーが適切な数量と適切な製品名を取得し、ビューがそれを表示することを期待しています。（非常に一般的）
確かに、ビジネスはアプリケーションが機能テストの一部で開発者が書いたのと同じように動作することを期待するので、この場合、受け入れテストは次のようになります：
Given Bobが製品リストページに入力し、「Nike basket n°2」製品の近くにある「addToBasket」ボタンをクリックすると、バスケットに数量「1」と「Nikeバスケット」が表示されます。 n°2 "。 （例による仕様）
どちらのテストも非常によく似ていますね。
だから私の質問は、機能テストと受け入れテストを並行して作成しながら、多くの重複コードと冗長テストを作成するリスクがあるのでしょうか？
良い習慣とは何ですか？機能テストを、例外的/バグのある動作、不整合な変数のシナリオなど、いくつかの純粋な技術的な事柄のみを実行し、受け入れテストでビジネスシナリオ全体を処理できるようにしますか？
私も言うでしょう：受け入れテストを非常に重視する場合、機能テストは本当に必要ですか？
はい、重複する可能性があります。多くの場合、基幹業務タイプのWebサイトでは、機能の実装に必要なコードの深さがそれほど大きくないため、受け入れテストが実際に開発者指向のテストの代わりになることがわかります。比較として、画像認識ソフトウェアは非常に奥行きがあるかもしれませんが、許容レベルでは、これを円として認識し、これを正方形として認識する必要があるため、単純な場合があります。開発者としては、画像キャプチャ、光補正、オブジェクト検出、オブジェクト認識、何とか何とかテストする必要があります。
したがって、受け入れから実装までの間に浅い量のコードがある場合、それは冗長であると感じることがよくあります。
ただし、プロセスに関しては他にもいくつかの違いがあります。あなたは一連の受け入れテストを構築することができ、それらは常にすべてに合格する必要はなく、それらはターゲットとして機能することができるので、すべてをノックするまで、合格した5％から10％から50％などに進みますテストオフ。場合によっては、理想的には、これらのテストは開発者とは無関係にまとめることができます。開発者向けのテスト。常に合格することを目的としています。
はい、テストは複数のレベル、複数の形式で存在する必要があり、はい、多くの冗長性があります。
たとえば、MVCでは、属性の値をチェックする3つの場所すべてでテストを行うことができます。これは、任意の部分を変更して、変更の影響を知ることができるので、前向きなものと見なすことができます。
だから、はい、あなたが言うように、異なるテストは異なるものをテストするべきです。データベーステストではCRUD操作を実行して結果を確認できます。ミドルウェアも同様にテストでき、実際に開発（TDD）を推進するために使用できます。
フロントエンドテストでは、出力デバイスやバージョンのバリエーションに関係なく、ユーザーが実際に意図した結果を表示できることを確認できます。