問題タブ [integration-testing]

「GenerateOrders」などの多数の「操作」またはテストを記述できる独自の統合テストハーネスを作成しました。テストの構成に使用できるパラメーターがいくつかあります（注文数など）。次に、テストが成功/失敗したことを確認するための2番目の操作を記述します（つまり、（nt）注文があります）。

ツールはのために使用されます

• 統合テスト
• データ生成
• エンドツーエンドのテスト（多数のテストを組み合わせて一致させることにより）

うまく機能しているようですが、新しいテストを維持および作成するには、開発経験が必要です。私たちのテストチームは、C＃開発の経験がほとんどない参加者になりたいと考えています。

私たちはちょうど新しいグリーンフィールドプロジェクトを開始しようとしています。私は統合テストを作成して維持するための最適な方法についていくつかの調査を行っています。

質問は次のとおりです。

• 統合テストをどのように実行しますか？
• どのツールを使用していますか（FitNess？、Custom？、NUnit）？

私は人々の提案/コメントを楽しみにしています。

前もって感謝します、

デビッド

与えられたソフトウェアが...

• システムはいくつかのサブシステムで構成されています
• 各サブシステムはいくつかのコンポーネントで構成されています
• 各コンポーネントは多くのクラスを使用して実装されています

... 各サブシステムまたはコンポーネントの自動テストを作成するのが好きです。

コンポーネントの各内部クラスのテストは作成しません (各クラスがコンポーネントのパブリック機能に貢献し、コンポーネントのパブリック API を介して外部からテスト可能/テストされる場合を除きます)。

コンポーネントの実装をリファクタリングするとき (新しい機能を追加する一環としてよく行う)、既存の自動テストを変更する必要はありません。テストはコンポーネントのパブリック API とパブリック API のみに依存するためです。通常、変更ではなく拡張されます。

このポリシーは、 Refactoring Test Codeのようなドキュメントとは対照的だと思います...

• 「...単体テスト...」
• 「...システム内のすべてのクラスのテストクラス...」
• 「... テスト コードと製品コードの比率は ... 理想的には 1:1 の比率に近づくと考えられています ...」

... 私はそのすべてに同意しないと思います (または、少なくとも練習していません)。

私の質問は、私のポリシーに同意しない場合、その理由を説明していただけますか? この程度のテストでは不十分なシナリオはどれですか?

要約すれば：

• パブリック インターフェイスはテスト (および再テスト) され、変更されることはほとんどありません (追加されることはありますが、変更されることはほとんどありません)。
• 内部 API は公開 API の背後に隠され、公開 API をテストするテスト ケースを書き直すことなく変更できます。

脚注: 私の「テスト ケース」の一部は、実際にはデータとして実装されています。たとえば、UI のテスト ケースは、さまざまなユーザー入力とそれに対応する予想されるシステム出力を含むデータ ファイルで構成されます。システムのテストとは、各データ ファイルを読み取り、システムへの入力を再生し、対応する期待される出力が得られることをアサートするテスト コードを用意することを意味します。

テスト コードを変更する必要はほとんどありませんが (通常、パブリック API は変更ではなく追加されるため)、既存のデータ ファイルを変更する必要がある場合があります (週に 2 回など)。これは、システム出力をより良いものに変更した場合 (つまり、新しい機能によって既存の出力が改善された場合) に発生する可能性があり、既存のテストが「失敗」する可能性があります (テスト コードは、出力が変更されていないことをアサートしようとするだけであるため)。これらのケースを処理するために、次のことを行います。

• 出力をアサートするのではなく、新しい出力を新しいディレクトリにキャプチャするように指示する、特別なランタイム フラグが設定された自動テスト スイートを再実行します。
• ビジュアル差分ツールを使用して、どの出力データ ファイル (つまり、どのテスト ケース) が変更されたかを確認し、これらの変更が適切であり、新しい機能が期待どおりであることを確認します。
• 新しい出力ファイルを新しいディレクトリからテスト ケースの実行元のディレクトリにコピーして、既存のテストを更新します (古いテストを上書きします)。

脚注: 「コンポーネント」とは、「1 つの DLL」または「1 つのアセンブリ」のようなものを意味します... アーキテクチャまたはシステムの配置図に表示されるのに十分な大きさのもので、多くの場合、数十または 100 のクラスを使用して実装されます。約1つまたは少数のインターフェースのみで構成されるパブリックAPIを使用...開発者の1つのチームに割り当てられる可能性があるもの（別のコンポーネントが別のチームに割り当てられる場合）、したがって、コンウェイの法則に従って比較的安定したパブリック API。

脚注: 記事Object-Oriented Testing: Myth and Realityは次のように述べています。

通説: ブラック ボックス テストで十分です。 クラス インターフェイスまたは仕様を使用して慎重にテスト ケースを設計すれば、クラスが完全に実行されたことを確認できます。ホワイトボックス テスト (テストを設計するためのメソッドの実装を見る) は、カプセル化の概念そのものに違反しています。

現実: OO 構造が重要、パート II。多くの調査によると、開発者が耐え難いほど完全であると考えているブラックボックス テスト スイートは、テスト対象の実装のステートメント (パスや状態は言うまでもなく) の 3 分の 1 から半分しか実行しないことが示されています。これには 3 つの理由があります。まず、選択された入力または状態は通常、通常のパスを実行しますが、可能なすべてのパス/状態を強制するわけではありません。第二に、ブラックボックステストだけでは驚きを明らかにすることはできません。テスト対象のシステムの指定されたすべての動作をテストしたとします。不特定の動作がないことを確認するには、システムの一部がブラックボックス テスト スイートによって実行されていないかどうかを知る必要があります。この情報を取得できる唯一の方法は、コード インストルメンテーションです。三番、

ホワイトボックスの機能テストを行っていることを付け加えておきます。コード (実装内) を確認し、機能テスト (パブリック API を駆動する) を作成して、さまざまなコード ブランチ (機能の実装の詳細) を実行します。

Maven には、統合テスト フェーズのライフサイクル用に定義された数百のテストがあり、完了するまでに長い時間がかかります。

私がやりたいことは、 で 1 つのテストだけを実行することですintegration-test。私はやってみました：

しかし、それは機能しません。は-Dtest、統合テスト フェーズではなく、単体テスト ゴールのテストのみを実行します。代わりに を試しました-Dintegration-test=<my-test>が、無視されました。

それを行う方法はありますか？

私の構成は次のとおりです。

私は、サードパーティベンダーのSQLiteデータテーブルからすべての行をプルし、それらのレコードからビジネスオブジェクトを作成し、新しいビジネスオブジェクトを別のクラスに送信するという任務を負っています。

擬似コード：

私はそれをすべて機能させています。

私の質問は、ユニットをテストできるようにこのクラスを作成するにはどうすればよいですか？

するべきか：

• リポジトリパターンを使用して、データアクセスをモックアウトします
• ユニットテストで実際にダミーのSQLiteデータベースを提供する

またはより良いアイデアはありますか？私はC＃を使用していますが、この質問は言語に依存しないようです。

cucumber で普及した Given/When/Then スタイルを使用して記述された C# 統合テストがいくつかあります。基本的に NBehave と同じように機能するフレームワークを使用しています。

私が直面している繰り返しの問題は、統合テストに必要なすべてのアプリケーション状態のセットアップと配線の問題です。私のテストのほとんどは次のようになります。

ご覧のとおり、アクションとアサーションは 1 行ですが、6 行の「配線」があります。私が行ったほぼすべてのテストで、これらの 6 行が繰り返されます。

これはコードの匂いのように思えますが、これを処理する方法がわかりません。6 行を 1 行 (Given "a valid system..."またはそのようなもの) にリファクタリングすることもできますが、それでは行き過ぎて、あまりにも多くの情報を隠してしまうようです。

この分野でより多くの経験を持つ他の人からの考えをいただければ幸いです。どうもありがとう。

私は単体テストを作成しました。外部リソースが必要な場合は、偽物を使用して処理します。

これまでのところ、すべて順調です。今、私は他のテストフェーズに直面しています。主に、データベースなどの実際の外部リソースに対してユニットテストメソッドを繰り返したい統合です。

では、ユニット対統合テスト用のテスト プロジェクトを構築するための推奨事項は何ですか? ユニットと統合のために別々のアセンブリを好む人がいることを理解していますか?

2 つのアセンブリ間で共通のテスト コードを共有するにはどうすればよいでしょうか。すべての抽象テスト クラスを含む 3 番目のアセンブリを作成し、ユニットと統合を継承させる必要がありますか? 私は最大限の再利用性を探しています...

Dependency Injection (StructureMap) について多くのノイズを耳にします。特定のユニット + 統合テスト セットアップでそのようなツールをどのように利用できますか?

誰かが知恵を共有できますか？ありがとう

Rails アプリでいくつかの機能テストを作成しようとしていますが、application_controller.rb には次のようなものがあります。

テストrequest.subdomainsを実行すると、探している有効なサブドメインが含まれておらず、機能テストを実行できません。

メソッドをスタブ化するか、オブジェクトcurrent_accountをモックすることは可能ですか?request.subdomains

自動テストを使用して、Web アプリケーションの機能を検証します。テストケースでのアサーションをより複雑で柔軟にするために、「TestID」の導入を検討しています。つまり、テストケースがページ上の要素を見つけて検証するのに役立つ HTML マークアップ内の ID です。さらに、これらの TestID により、ページ上のデータが限られているために現在不可能な、より具体的な統合テストが可能になります。

しかし、次の点が私たちを躊躇させます。

• テスト ID の導入は、テスト用にテスト済みを変更することを意味します
• セキュリティ- 内部ドメイン オブジェクト ID と、そうでなければページに表示されないその他の情報を開示します。
• 標準- TestID をマークアップにどのように配置するかによって、要素または属性の意図されたセマンティックな使用に違反する可能性が高くなります (たとえば、「id」または「class」属性、その他の html 要素など)。
• 干渉- TestID がアプリケーション コードに干渉する可能性がある
• パフォーマンス- TestID は (ユーザーにとって) 不要なマークアップであり、ページ サイズを増加させます (大きなページでのみ重要です)。

TestID をテスト/ステージング HTML に制限することは良い考えではないようです。なぜなら、本番環境で使用されるコードをテストしたいのは明らかであり、テスト/ステージング環境が異なる動作をすることを望んでいないからです。実際、現在、リリース後にライブ システムに対してテスト スイートの一部を実行しています。

TestID は良いアイデアだと思いますか? もしそうなら、どのようにマークアップに入れますか?

私が話していることを示すためのいくつかのサンプルマークアップ: