2

コンテキストは次のとおりです。データベースに多くのレガシー コードを含む MVC Web アプリケーションがあります。(このコードをサーバー側に移行することは許可されていません) 永続ストアには、リポジトリパターンを使用します。

私たちのクライアントはアプリケーションに新しい機能を追加したいと考えているので、サーバー側にすべての新しいビジネス ロジックを追加したことは明らかです。

私たちが現在抱えている問題は、毎日実行速度が遅くなる機能テスト スイートに関するものです。

主な理由は、セレンを使用してブラウザーからデータベースへのテストを実行しているためです (エンドツーエンド)。

人々が次の他の戦略を使用して成功しているかどうかを知りたいです:

1. UI を取り除く

ブラウザーや Web サーバーを経由する代わりに、コントローラー レベルでテストを実行します。UI によるテストの損失を補うために、javascript 単体テストまたは MVC Views 単体テストを記述します。

2. DB を取り除く

アプリケーションがメモリ内で完全に実行できるように、レポジトリの「InMemory」バージョンを作成します。これにより、テスト スイートも高速化されます。これを補うために、データベース リポジトリの統合テストを作成します。

1+2 の両方の戦略を実行すると、実行速度が最大になると思います。本当に重要なもの (コントローラー、ビジネス レイヤー、ドメイン エンティティ、さまざまなヘルパーが統合されたもの) をテストします (UI と DB は「詳細」と見なします)。 」）。

さて、問題は、実際にはDBには多くのレガシーコードがあるため、そのようなものの統合テストに頼り、DBを機能テストスイートから除外するだけで安全かどうかわからないことです. とにかくスイートのままにしておくべきですか？それとも大丈夫ですか？

どんな経験や提案も大歓迎です!

私の調査結果のいくつかは次のとおりです。

  • 継続的デリバリーの本は、これらのテストは遅くても常にエンド ツー エンドであるべきだと示唆しています (ただし、誰もがそれに同意するわけではないとも述べています)。
  • 私の理解では、ボブおじさんは 1+2 戦略に同意するでしょうが、レガシー コードを含むデータベースでそう考えるかどうかはわかりません。
4

1 に答える 1

2

テスト期間の延長が主な懸念事項です。最終的には、いくつかのテストを放棄しなければならないところまで成長します。滑りやすい坂です。

それを未然に防ぐために、私は確かに 1+2 戦略を採用しますが、エンド ツー エンドのテストもある程度維持します。

UI と DB をバイパスするテストをどんどん追加するにつれて、冗長なエンド ツー エンド テストと、システムが適切に接続されていることをテストするために必要なテストを判断し始めることができます。

最終的には、エンド ツー エンド テストが純粋に配管テストであり、すべてのビジネス ルールとプレゼンテーション動作が 1+2 戦略を使用してテストされることが目標です。

ストアド プロシージャは複雑です。データベース コードに追加機能がない限り、おそらくそれを管理できます。実際、そのデータベース コードの一部を徐々にサーバー コードに置き換えることができれば、状況は改善されます。データベース コードの一部は、システムの残りの部分が存在しなくてもテストできます。また、データベースの動作の一部を模倣できます。残念ながら、エンド ツー エンドでしかテストできない動作もおそらく存在するため、レガシー データベース コードが存在する限り、それらのテストを実施しておく必要があります。

ここで最も重要な要素は、物事をゆっくりと進め、後戻りを避けることです。「テストを修正する」ために巨大なプロジェクトに着手しないでください。代わりに、段階的な改善を行ってください。「ボーイスカウトのルール」を実践し、常に自分が見つけた以上のテストを残してください。それらを悪化させないでください。少しずつ、より多くのテストを戦略 1+2 に移行します。置き換えても問題ないと思うストアド プロシージャを少しずつ置き換えます。最も冗長なエンド ツー エンド テストを徐々に削除します。

于 2012-10-05T14:10:42.040 に答える