タグ付けされた質問 「integration-tests」

統合テストは、個々のソフトウェアモジュールを組み合わせてグループとしてテストするソフトウェアテストのフェーズです。モックやスタブは必要ありません。すべてが本番環境と同じようにテストされます。

11
（データベース）統合テストは悪いですか？
一部の人々は、統合テストはすべての種類の悪い点と間違っていると主張しています -すべてを単体テストする必要があります。さまざまな理由で、私は常に好きではないオプション。 場合によっては、単体テストでは何も証明されないことがわかります。 例として、次の（PHPでの）単純な（単純な）リポジトリー実装を取り上げましょう。 class ProductRepository { private $db; public function __construct(ConnectionInterface $db) { $this->db = $db; } public function findByKeyword($keyword) { // this might have a query builder, keyword processing, etc. - this is // a totally naive example just to illustrate the DB dependency, mkay? return $this->db->fetch("SELECT * …
9
CIサーバーで単体テストを実行する意味は何ですか？
CIサーバーで単体テストを実行するのはなぜですか？ 確かに、何かがマスターにコミットされる頃には、開発者はすでにすべての単体テストを実行し、新しいコードで発生した可能性のあるエラーを修正しています。それは単体テストのポイントではありませんか？そうでなければ、彼らは壊れたコードをコミットしたばかりです。
8
広範囲にモックせずにユニットテストをどのように正確に記述する必要がありますか？
私が理解しているように、ユニットテストのポイントは、コードのユニットを単独でテストすることです。この意味は： コードベースの他の場所にある無関係なコードの変更によって壊れてはなりません。 統合テスト（ヒープで破損する可能性がある）とは対照的に、テストされたユニットのバグによって破損するユニットテストは1つだけです。 これはすべて、テストされたユニットのすべての外部依存関係をモックアウトする必要があることを意味します。そして、ネットワーク、ファイルシステム、データベースなどの「外部レイヤー」だけでなく、すべての外部依存関係を意味します。 これは、事実上すべての単体テストがモックする必要があるという論理的な結論につながります。一方、モックに関するGoogleの簡単な検索では、「モッキングはコードのにおい」であると主張する記事が数多くあり、ほとんど（完全にではありませんが）回避する必要があります。 さて、質問へ。 ユニットテストはどのように適切に書かれるべきですか？ それらと統合テストの間の境界線は正確にどこにありますか？ アップデート1 次の擬似コードを検討してください。 class Person { constructor(calculator) {} calculate(a, b) { const sum = this.calculator.add(a, b); // do some other stuff with the `sum` } } 依存関係Person.calculateをモックせずにメソッドをテストするテストCalculator（Calculator「外の世界」にアクセスしない軽量クラスであることを考えると）は、単体テストと見なすことができますか？
7
単体テストの代わりに受け入れテストと統合テストを使用するだけで十分ですか？
この質問の簡単な紹介。私は現在TDDと最近BDDを1年以上使用しています。私は、モックなどの手法を使用して、テストをより効率的に記述します。最近、私は自分のために小さなお金管理プログラムを書くための個人的なプロジェクトを始めました。レガシーコードがなかったため、TDDから始めるのに最適なプロジェクトでした。残念ながら、TDDの喜びはあまり経験しませんでした。それは私の楽しみを台無しにし、プロジェクトをあきらめました。 なにが問題だったの？さて、TDDのようなアプローチを使用して、テスト/要件がプログラムの設計を進化させました。問題は、テストの作成/リファクタリングに関して、開発時間の半分以上がかかっていたことです。したがって、リファクタリングして多くのテストに書き込む必要があるため、最終的にはこれ以上機能を実装したくありませんでした。 職場では、レガシーコードがたくさんあります。ここでは、統合テストと受け入れテストを増やし、単体テストを減らしていきます。ほとんどのバグは受け入れテストと統合テストによって検出されるため、これは悪いアプローチではないようです。 私の考えは、最終的には単体テストよりも多くの統合テストと受け入れテストを書くことができるということでした。バグを検出するために言ったように、単体テストは統合/受け入れテストよりも優れていません。単体テストも設計に適しています。私はそれらの多くを書いていたので、私のクラスは常にテストしやすいように設計されています。さらに、テスト/要件が設計をガイドできるようにするアプローチは、ほとんどの場合、より良い設計につながります。単体テストの最後の利点は、高速であることです。ユニットテストとほぼ同じ速度で実行できることを知るために、十分な統合テストを作成しました。 ウェブを調べた後、私の考えによく似たアイデアがあちこちであることがわかりました。この考えをどう思いますか？ 編集 質問には、デザインは良かったが、次の要件のために大規模なリファクタリングが必要な例の1つに答えました。 最初は、特定のコマンドを実行するためのいくつかの要件がありました。拡張可能なコマンドパーサーを作成しました。これは、ある種のコマンドプロンプトからコマンドを解析し、モデル上で正しいものを呼び出しました。結果は、ビューモデルクラスで表されました。 ここには何も問題はありませんでした。すべてのクラスは互いに独立しており、新しいコマンドを簡単に追加し、新しいデータを表示できました。 次の要件は、すべてのコマンドに独自のビュー表現（コマンドの結果の何らかのプレビュー）が必要であることです。新しい要件に対してより良い設計を実現するために、プログラムを再設計しました。 これは、すべてのコマンドに独自のビューモデルがあり、したがって独自のプレビューがあるためです。 問題は、コマンドパーサーがコマンドのトークンベースの解析を使用するように変更され、コマンドを実行する機能が削除されたことです。すべてのコマンドには独自のビューモデルがあり、データビューモデルは、表示する必要があるデータを知っている現在のコマンドビューモデルのみを知っています。 この時点で私が知りたかったのは、新しいデザインが既存の要件を満たさなかった場合のみです。受け入れテストを変更する必要はありませんでした。ほぼすべての単体テストをリファクタリングまたは削除する必要がありましたが、これは膨大な作業の山でした。 ここで見せたかったのは、開発中によく発生する一般的な状況です。古いデザインでも新しいデザインでも問題はありませんでした。要件に応じて自然に変更されただけでした。私がどう理解したか、これはTDDの利点の1つであり、デザインが進化します。 結論 すべての答えと議論をありがとう。この議論の要約として、次のプロジェクトでテストするアプローチを考えました。 まず、いつものように何かを実装する前に、すべてのテストを作成します。 要件については、最初にプログラム全体をテストする受け入れテストをいくつか作成します。次に、要件を実装する必要があるコンポーネントの統合テストをいくつか作成します。この要件を実装するために別のコンポーネントと密接に連携するコンポーネントがある場合、両方のコンポーネントが一緒にテストされる統合テストも作成します。最後になりましたが、アルゴリズムまたは他のクラスを高い順列（シリアライザーなど）で記述する必要がある場合は、この特定のクラスの単体テストを記述します。他のすべてのクラスはテストされませんが、単体テストが行​​われます。 バグについては、プロセスを簡素化できます。通常、バグは1つまたは2つのコンポーネントによって引き起こされます。この場合、バグをテストするコンポーネントの統合テストを1つ作成します。アルゴリズムに関連する場合は、ユニットテストのみを記述します。バグが発生したコンポーネントを簡単に検出できない場合、受け入れテストを作成してバグを特定します。これは例外です。
5
スタブとすべてを公開する単体テストのポイントはありますか？
「適切な」方法でユニットテストを行う場合、つまり、すべてのパブリックコールをスタブ化し、プリセット値またはモックを返す場合、実際には何もテストしていないように感じます。文字通り、コードを見て、パブリックメソッドを通るロジックのフローに基づいて例を作成しています。そして、実装が変更されるたびに、それらのテストを行って変更する必要があります。これは、（中期でも長期でも）何か有用なことを達成しているとは感じません。また、統合テスト（非幸福なパスを含む）も行いますが、テスト時間が長くなることはあまり気にしません。それらで、私は実際に回帰をテストしているように感じます。なぜなら、それらは複数をキャッチしたからです。一方、ユニットテストは、パブリックメソッドの実装が変更されたことを示しています。 単体テストは広大なトピックであり、私はここで何かを理解していないと感じています。単体テストと統合テストの決定的な利点は何ですか（時間のオーバーヘッドを除く）。
5
すでに統合テストがある場合、ユニットテストが必要ですか？
私のプログラムの統合テストがすでにあり、それらすべてが合格した場合、それはうまくいくと感じています。次に、単体テストを作成/追加する理由は何ですか？とにかく統合テストを書く必要があるので、統合テストでカバーされていない部品の単体テストのみを書きたいと思います。 統合テストよりも単体テストの利点を知っているのは 小さく、したがって高速に実行できます（ただし、テストに新しいユニットを追加すると、統合テストで既にテストされているため、テストスーツ全体が大きくなり、実行時間が長くなります） 1つのことしかテストしないため、バグを見つけやすくなります（ただし、統合テストが失敗した場合は、個々のパーツを検証するために単体テストの書き込みを開始できます） 統合テストで検出されない可能性のあるバグを見つけます。たとえば、マスキング/オフセットのバグ。（ただし、統合がすべてのパスをテストする場合、プログラムは隠れたバグが存在する場合でも動作します。したがって、将来の統合テストを中断したり、パフォーマンスの問題を引き起こさない限り、これらのバグを見つける/修正することは優先度が高くありません） そして、私たちは常により少ないコードを書きたいのですが、単体テストを書くにはもっと多くのコードが必要です（主にモックオブジェクトをセットアップします）。単体テストと統合テストのいくつかの違いは、単体テストではモックオブジェクトを使用し、統合テストでは実際のオブジェクトを使用することです。重複が多く、コードの動作を変更するためのオーバーヘッドが追加されるため、テストでもコードの複製は好きではありません（リファクタリングツールは常にすべての作業を行うことはできません）。
3
統合テストは設計をどのように批判しますか？
統合テストに関するJB Rainsbergerのブログ投稿を読んでいますが、どのように統合テストが私たちの設計により厳しいのでしょうか？ より統合されたテストを作成します。これはより大きく、マイクロテストのように設計を厳しく批判しません。
3
統合テストはすべての単体テストを繰り返すことを意図していますか？
関数があるとしましょう（Rubyで書かれていますが、誰でも理解できるはずです）： def am_I_old_enough?(name = 'filip') person = Person::API.new(name) if person.male? return person.age > 21 else return person.age > 18 end end 単体テストでは、すべてのシナリオをカバーする4つのテストを作成します。それぞれはPerson::API、スタブ化されたメソッドmale?とでモックされたオブジェクトを使用しますage。 次に、統合テストを作成します。Person :: APIはもうm笑されるべきではないと思います。したがって、Person :: APIオブジェクトをモックせずに、まったく同じ4つのテストケースを作成します。あれは正しいですか？ はいの場合、単体テストを書く意味は何ですか、自信を与える統合テストを書くことができたら（スタブやモックではなく、実際のオブジェクトで作業している場合）？
9
ユニットテストは後でコメントアウトされる傾向があるため、または統合テストはより価値があるため、ユニットテストを作成しないのは合理的ですか？
私は同僚とユニット/統合テストについて話し合っていましたが、彼はユニットテストの作成に対して興味深いケースを作りました。私は大規模なユニットテスト（主にJUnit）の支持者ですが、彼がいくつかの興味深い点を指摘したので、他の人の意見を聞くことに興味があります。 彼のポイントを要約するには： 主要なコードの変更（POJOの新しいセット、主要なアプリケーションのリファクタリングなど）が発生した場合、単体テストは修正されるのではなくコメントアウトされる傾向があります。 ユースケースをカバーする統合テストにより多くの時間を費やすことができます。これにより、より小さなスコープのテストの重要性が低くなります。 これについての考え？統合テストは少なくとも同じくらい価値があるように聞こえますが、私はまだプロユニットテストです（一貫して改善されたコードを生成しているのを見ています）。
7
統合テストはいつ書くべきですか？
TDDユニットルールのルールによれば、製品コードの前に記述されていますが、具体的な（モックではない）ワイヤードオブジェクト間の相互作用を実行する統合テストについてはどうでしょうか。 「配線」をテストするためだけに、単体テストの前に作成するか、製品コードの後に​​作成する必要がありますか？ 私は、受け入れテストや機能テストではなく、低レベルの統合テストについて話していることに注意してください。
6
データベースとユニット/統合テスト
Webアプリケーションを使用したユニット/統合テストについて誰かと話し合いをしましたが、1つのコアアイデアについて意見の相違があります。問題は、ユニットテストの対象となるデータベースにデータを事前に入力しておくべきだと考えている人が話していることであり、テストの実行前後に完全に空である必要があると思います。 データベースに事前入力されたデータに関する私の懸念は、データが良好な状態に維持されることを確認する方法がないことです。テスト自体はデータベース内のデータを作成、削除、変更するため、テストを開始する前にデータベースにデータを保持するのは良いことではありません。 データベースの機能をテストする最良の方法は、次のセットアップを行うことです。 テストを実際に実行する前の「セットアップ」フェーズでは、まずデータベース内のすべてのテーブルを切り捨てます 次に、実行しようとしているテストケースに必要なすべてのデータを挿入します 次に、テストケースを実行して検証します 次に、「ティアダウン」フェーズで、データベース内のすべてのテーブルを再度切り捨てます テスト対象のデータがテスト可能な優れたテストであることを保証する他の良い方法はありません。 ここに何かが足りませんか？これは、データベース関連の機能をテストする最良の方法ではありませんか？（テストを開始する前、またはテストが完了した後でも）データベースに常に存在するデータベースを事前に設定しておくと、メリットがありますか？私のプロセスを異なる方法で説明して、私のポイントをよりよく理解するためのアイデアの助けも素晴らしいでしょう（つまり、私のポイントにメリットがある場合）。
2
統合テストではモックを使用しますか？
私は現在、学期プロジェクトのために、単体テストや統合テストなど、複数のタイプのテストを実行する必要があるソフトウェアテストのクラスにいます。統合テストの場合、教授は統合テストにモックとモック作成ライブラリ（EasyMockやMockitoなど）を使用すると言いました。私はかなり混乱しています。統合テストとは、クラス、モジュール、サービスなどの外部をテストすることです。複数のクラスとサービスをテストする場合、統合テストでモックとスタブを使用するのが適切なのはなぜですか？
4
インタープリター言語にCIを使用するにはどうすればよいですか？
これまでに継続的インテグレーションシステム（CI）を使用したことがありません。私は主にMATLAB、PythonまたはPHPでコーディングします。これらのどちらにもビルドステップがなく、CIがどのように作業に使用できるかわかりません。大企業の大規模プロジェクトの友人から、言葉は関係ないと言われました。 ビルドステップがない場合、CIがどのように役立つかわかりません。CIは、単体テストを実行するテスト環境と考えることができます。何か不足していますか？
8
膨大な数の失敗したテストに対処する方法は？[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 私はJavaで書かれた古いプロジェクトの開発に取り組んでいます。LOCは1,000万を超え、さらに悪いことに、4000を超える機能テストがあります。 Hudsonによってスケジュールされたテストは、大きなコード変更のたびに狂ったように失敗しています。テストの失敗の検証-製品またはテストに問題がある場合、数か月かかります。何をテストしているかわからないため、古いテストを削除することはできません！ 私たちにできることは？そのような量のレガシーテストをどのように進めるのですか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.