問題タブ [integration-testing]

単体テストと統合テストのいわゆる教科書的な定義を知っています。私が興味を持っているのは、単体テストを作成する時期です...できるだけ多くのクラスのセットをカバーするように記述します。

たとえば、クラスがある場合、クラスWordの単体テストをいくつか作成しWordます。次に、Sentenceクラスの作成を開始し、クラスと対話する必要がある場合は、少なくともそれらが対話する場所でWord両方をテストするように単体テストを作成することがよくSentenceあります。Word

これらのテストは、これら 2 つのクラスの統合をテストするようになったため、本質的に統合テストになりましたか? それとも、2 つのクラスにまたがる単なる単体テストですか?

一般に、この不確実な行のために、実際に統合テストを作成することはめったにありません...または完成品を使用して、すべての部分が実際の統合テストで適切に機能するかどうかを確認します.手動であり、範囲を超えて繰り返されることはめったにありません.個々の機能の？

統合テストを誤解していますか、それとも統合テストと単体テストの違いは本当にほとんどないのでしょうか?

いくつかのテスト データ ジェネレーターがあることは知っていますが、ほとんどの場合、名前と住所のスタイル データベースを埋めるだけのようです [お気軽に訂正してください]。

統合され正規化された大規模なアプリケーションがあります。たとえば、請求書には、在庫テーブルにリンクされた部品番号、顧客テーブルにリンクされた顧客番号、監査情報にリンクされた変更ログなどがあり、ランダムに入力することは明らかに困難です。現在、実際のデータを難読化してテスト データを取得しています (ただし、あまりうまくいきません)。

テスト用の大量のデータを作成するために、どのツールや方法を使用していますか?

NUnit または MBUnit 内から Web サービスの統合テストを行いたいと考えています。これについてはまだ深く掘り下げていませんが、これを行うには「単体テスト」で WebDev.WebServer.exe を起動する必要があると確信しています。(実際には単体テストではないことはわかっています)。

はい、Web サービスが独自に使用する基礎となるオブジェクトをテストできます (私もそうです)。しかし、この場合のテストに興味があるのは、プロキシがすべて機能し、期待どおりに処理されることなどです。

何かアドバイス？

モデル ベース テストで使用した戦略は何ですか?

• 統合テスト専用に使用しますか、それとも他の領域 (ユニット/機能/システム/仕様検証) に拡張しますか?
• 焦点を絞った「封印された」モデルを構築しますか、それとも複雑なオニバス モデルを徐々に進化させますか?
• 製品サイクルのどの時点で MBT の作成に投資しますか?
• MBT 専用に作成するベース テスト ライブラリはどのようなものですか?

• MBT をより適切にサポートするために、機能ベースのテスト ライブラリにどのような違いを加えていますか?

統合サーバーをセットアップしていますが、ビルドを完了するために複数のタスクを使用することに関する最善のアプローチについて疑問があります。すべてを 1 つの大きなジョブに設定するか、小さな依存ジョブを作成するのが最善の方法ですか?

私たちは、新しい/変更されたGUI機能の測定を伴う大規模なプロジェクトに取り組んでいます。過去に、新しい機能を追加するときに、関連するコードに新しい問題が頻繁に発生することがわかりました。

技術者以外のユーザーにもテストを実施してもらいますが、多くの場合、パーツを見逃してバグをすり抜けてしまいます。

WinFormsプロジェクトのUIテストを整理するためのベストプラクティスはありますか？それを自動化する方法はありますか？

私は自分の製品で一連の統合テストを実行するためのツールを書いています。それをインストールしてから、それに対して一連のコマンドを実行して、想定どおりに動作することを確認します。私は、各テストケースのコマンドをマークアップする方法についてさまざまなオプションを検討しており、人々がこれについて共有する洞察を持っているかどうか疑問に思っています。私はYAMLを使用して、次のようなことをすることを考えています（レールフィクスチャから適応したものです）：

誰かが別の、またはより良いアイデアを持っていますか？または、私が知らないドメイン固有言語はありますか？

次のようなコントローラメソッドが与えられます：

リターンに期待されるXMLがあることを主張する統合テストを作成するための最良の方法は何ですか？

あなたのほとんどは自動化されたテストをたくさん書いていて、単体テストの際にいくつかの一般的な落とし穴に遭遇したこともあると思います。

私の質問は、将来の問題を回避するために、テストを作成するための行動規則に従っていますか? より具体的に言えば、優れた単体テストの特性とは何か、またはテストをどのように作成するのか?

言語にとらわれない提案が奨励されます。

データ アクセス レイヤーのみ、またはアプリケーション スタックの大部分を使用して統合テストを行っている場合。複数のテストが同じデータベースで実行されている場合、それらが互いに衝突するのを防ぐ最善の方法は何ですか?