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

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

4
BDDは中規模から大規模のプロジェクトに拡張可能ですか？
BDD（Behaviour Driven Development）について読んだすべてのWebサイトで、要件を定義することがいかに明白で簡単かを示す非常にシンプルで素晴らしい例が見つかります。しかし、このプロセスを（電卓の例ではなく）大きな製品に実装しようとすると、物事がかなり複雑で読みにくくなる（または得られる）ことがわかりました。特に後でリクエストを変更することは、このための統合テストを修正するための多くの作業を意味します。 だから、BDDは本当に価値があるのだろうか？他の手法では解決できない問題を解決できますか？
5
Webサービス呼び出しを必要とするクラスを単体テストするにはどうすればよいですか？
いくつかのHadoop Webサービスを呼び出すクラスをテストしようとしています。コードはほぼ次の形式です。 method() { ...use Jersey client to create WebResource... ...make request... ...do something with response... } たとえば、ディレクトリ作成メソッド、フォルダ作成メソッドなどがあります。 コードが私が制御できない外部Webサービスを処理していることを考えると、これをどのように単体テストできますか？Webサービスのクライアント/レスポンスをモックすることはできましたが、最近見た「所有していないオブジェクトをモックしないでください」というガイドラインに違反しています。ダミーのWebサービス実装をセットアップできます。それでも「単体テスト」を構成できますか、それとも統合テストになりますか？この低いレベルで単体テストを実行することはできませんか？TDD実践者はどのようにこれに取り組むのでしょうか？
7
チームの新人でありながら、既存の統合と単体テストの品質について何ができますか？
私がキャリアで出くわした繰り返しのテーマは、チームに到着する新しい開発者であること、そして既存のユニットと統合テストスイートに対する固有の不信をすぐに持つことです。 面接中に、経営陣から「ユニットテストを強力にサポートしている」ことと、それを公然と奨励していることが伝えられます。彼らはそうしますが、テスト自体についてのすべては単に間違っています。100％の統合テストカバレッジがあり、10％未満の反復可能な単体テストカバレッジがある場合、100％のカバレッジを主張しているという事実と同様です。私が見つけた他のいくつかの問題： 単体テストと統合テストの間に明確な兆候はありません。単体テストと統合テストは、同じクラスに混在しています。 特定の環境のデータベース上の非常に特定の動的データに対する未宣言の明示的な依存関係がある統合テスト。 非トランザクション統合テスト。基本的には、後からクリーンアップするかどうかわからないテストであり、テストを再現可能にするために手動のデータベース「スクラビング」が必要になる場合があります。 モッキングは一切行われません。アプリケーションコードでは、モッキングを可能にするためだけに大幅な見直しが必要です。つまり、テストを考慮せずに設計します。 テスト名をすばやく確認して、実行中のテストを大まかに判断するための明確な命名規則はありません。 これは、すべてのテストが役に立たないか悪いというわけではなく、かなりの数のテストが非常に良く、維持する価値があると言っているわけではありませんが、金のためにパンするような気がします。ブラックボックステストケースのデータベースを台無しにするのが怖かったからといって、意図的にテストを実行することは避けました。 これは本質的に、私が個人的に何らかの方法で書いたりレビューしたりしていないユニットおよび統合テストの固有の不信感を与えました。あるレベルでは、テストスイートの品質を信頼していない場合、チームやプロジェクトにはまったく価値がありません。 この状況に陥ったとき、あなたはどうしますか？攻撃の最善の計画は、このようなものに取り組むことだと思いますか？ すべてのテストをリリース間で途方もない努力でリファクタリングする必要がありますか？このレガシープロジェクトが1日の強固な単体テストの対象となる可能性があるという考えを捨てる必要がありますか？
3
ユニットテストC ++：テスト対象
TL; DR 優れた有用なテストを書くのは難しく、C ++でのコストは高くなります。経験豊富な開発者は、何をいつテストするかについての論理的根拠を共有できますか？ 長い話 私はチーム全体でテスト駆動開発を行っていましたが、実際にはうまくいきませんでした。多くのテストがありますが、実際のバグやリグレッションがあるケースをカバーすることはないようです-通常、ユニットが相互作用しているときに発生し、孤立した動作からではありません。 これは多くの場合、ユニットレベルでテストするのが非常に難しいため、TDDの実行を停止し（開発を実際にスピードアップするコンポーネントを除く）、代わりに統合テストの対象範囲を増やすためにより多くの時間を費やしました。小規模なユニットテストは実際のバグをキャッチすることはなく、基本的にメンテナンスオーバーヘッドにすぎませんでしたが、統合テストは本当に努力する価値がありました。 今、私は新しいプロジェクトを継承しましたが、それをテストする方法を知りたいと思っています。ネイティブのC ++ / OpenGLアプリケーションであるため、統合テストは実際にはオプションではありません。しかし、C ++でのユニットテストはJavaよりも少し難しく（明示的にものを作成する必要がありますvirtual）、プログラムはオブジェクト指向ではないため、いくつかのものをモック/スタブすることはできません。 テストを書くためにいくつかのテストを書くためだけに、すべてを引き裂いてオブジェクト指向化したいとは思いません。だから私はあなたに尋ねています：それは何のためにテストを書くべきですか？例えば： 頻繁に変更する予定の関数/クラス 手動でテストするのがより難しい関数/クラス？ すでにテストが簡単な関数/クラス？ 敬意を表するいくつかのC ++コードベースを調べて、テストがどのように行われるかを確認し始めました。今はChromiumのソースコードを調べていますが、コードからテストの理論的根拠を抽出するのは難しいと感じています。人気のあるC ++ユーザー（委員会、本の著者、Google、Facebook、Microsoftなど）がこれにどのようにアプローチしているかについて、良い例や投稿がある場合は、さらに役立つでしょう。 更新 これを書いて以来、私はこのサイトとウェブを探索しました。良いものを見つけました： 単体テストを行わないのはいつが適切ですか？ /programming/109432/what-not-to-test-when-it-comes-to-unit-testing http://junit.sourceforge.net/doc/faq/faq.htm#best 悲しいことに、これらはすべてJava / C＃中心です。Java / C＃で多くのテストを作成することは大きな問題ではないため、通常は利益がコストを上回ります。 しかし、上で書いたように、C ++ではより困難です。特に、コードベースがそれほどオブジェクト指向でない場合は、ユニットテストのカバレッジを良好にするために、物事をひどく混乱させる必要があります。例えば、私が継承したアプリケーションにGraphicsは、OpenGLの上にある薄層の名前空間があります。すべてのエンティティをテストするには、すべてのエンティティがその機能を直接使用するため、これをインターフェイスとクラスに変換し、すべてのエンティティに挿入する必要があります。それはほんの一例です。 したがって、この質問に答えるとき、テストを書くためにかなり大きな投資をしなければならないことに注意してください。
4
データの配置が面倒すぎる場合のテスト方法
私はパーサーを書いており、その一部として、Expander単一の複雑なステートメントを複数の単純なステートメントに「拡張」するクラスがあります。たとえば、これはこれを展開します： x = 2 + 3 * a に： tmp1 = 3 * a x = 2 + tmp1 今、私はこのクラスをテストする方法、具体的にはテストを配置する方法を考えています。入力構文ツリーを手動で作成できます。 var input = new AssignStatement( new Variable("x"), new BinaryExpression( new Constant(2), BinaryOperator.Plus, new BinaryExpression(new Constant(3), BinaryOperator.Multiply, new Variable("a")))); または、文字列として記述して解析することもできます。 var input = new Parser().ParseStatement("x = 2 + 3 * a"); …
1
ファイルリーダーをテストするにはどうすればよいですか？
私はいくつかのファイル形式のプロジェクトに取り組んでいます。一部の形式は.xsdsによって指定され、他の形式はそれぞれのWebサイトのドキュメントによって指定され、一部はドキュメントのないカスタムの社内形式です。ムワハハハハ。 どうしたの？ ファイルリーダーをテストしたいと思いますが、これを実行する方法が完全にはわかりません。アプリケーションのフローは次のとおりです。 file.___ ===> read by FileReader.java ===> which creates a Model object どこFileReaderインタフェースがあります public interface FileReader { public Model read(String filename); } Modelファイルが読み込まれたときに移入された属性の数を持っています。次のように見えます public class Model { List<String> as; List<String> bs; boolean isAPain = true; // ... } 私は何を試しましたか？ 私の唯一のアイデアは、各ファイル形式のファイル「ジェネレーター」を作成することでした。これらのジェネレーターは基本的に、いくつかの変数（たとえば、ファイルで生成するコメントの数）を受け取り、サンプルファイルを出力してから読み込み、結果Modelを最初にファイルの生成に使用した変数と比較するビルダーです。 ただし、これにはいくつかの問題があります。 生成されるファイルは、実際のファイルのようには見えません。ジェネレーターはコンテキストをまったく認識しません。 私が手動で変数を設定しているので、ジェネレータがエッジケース用に生成したかどうかを認識するのは困難です。この方法は、1ダースのサンプルファイルを作成するよりもましです。 これを行うためのより良い方法はありますか？ 編集：それは私が実際に意味するものなので、ユニットを統合に変更しました。 EDIT2：これは私が言及したエッジケースの例です。 各ファイルは、頂点とエッジで構成されるグラフを表します。これらの頂点とエッジはさまざまな方法でアタッチできます。 v1 …
6
リポジトリメソッドをテストするためにユニットテストが必要なのはなぜですか？
私は経験不足のためにそれをうまく防御できないので、この質問について少し主張する悪魔を演じる必要があります。これが契約です。概念的には、単体テストと統合テストの違いを理解できます。永続化メソッドとリポジトリに特に焦点を当てる場合、単体テストでは、おそらくMoqなどのフレームワークを介してモックを使用し、検索された順序が期待どおりに返されたと主張します。 次の単体テストを作成したとしましょう。 [TestMethod] public void GetOrderByIDTest() { //Uses Moq for dependency for getting order to make sure //ID I set up in 'Arrange' is same one returned to test in 'Assertion' } したがって、セットアップしOrderIdExpected = 5て、モックオブジェクトが5IDとして返されると、テストに合格します。わかった。コードを単体テストして、コードのプリフォームが期待するオブジェクトとIDを返し、他の何かは返さないことを確認しました。 私が得る議論はこれです： 「なぜ単体テストをスキップして統合テストを行わないのですか？データベースのストアドプロシージャとコードを一緒にテストすることが重要です。テストに時間がかかることはわかっていますが、テストを実行してテストする必要があるので、両方を持っていても意味がありません。重要なことをテストするだけです。」 「まあ、それは統合テストであり、ユニットテストとしてコードを個別にテストする必要があります。やだ、やだ、やだ...」などの教科書の定義でそれを守ることができます。対現実は失われつつあります。私は時々これに出くわし、最終的に外部依存関係に依存する単体テストコードの背後にある理由を擁護できない場合、それを主張することはできません。 この質問に関するヘルプは大歓迎です、ありがとう！
1
単体テストと統合テストを分離する必要がありますか？
プロジェクトの単体テストと統合テストを作成する必要があります。 すべてのテストを単一のテストフォルダーに入れる必要がありますか？ または、単体テストと統合テストをそれぞれ個別のテストフォルダーに配置する必要がありますか？ それとも、それらを別々のプロジェクトに入れるべきですか？ それらをまとめると、このアプローチには利点や欠点がありますか？
3
外部APIを照会することが唯一の目的であるが、APIは複雑な照会構文を使用する関数をどのようにテストしますか？
唯一の実際のロジックは、外部APIのクエリ構文にあります。APIを照会するかどうかをテストするのではなく、正しいデータが返されるような方法で照会することをテストする必要があります。たとえば、いくつかの擬似コード： function retrieve_related_data(id) { query = "[potentially long, syntactically complex query that uses param id to get some data]"; results = api_wrapper.query(query); return results; } 構成されたAPIを使用したより具体的な例： function retrieveLifeSupportingObjectsWithinRegion(id) { query = " within region(" + id + ") as r find objects matching hydration>0 and temp_range has 75 send name, …
6
TDDの観点から、モックではなくライブエンドポイントに対してテストする場合、私は悪い人ですか？
私はTDDを宗教的に守ります。私のプロジェクトは通常、テストカバレッジが85％以上であり、意味のあるテストケースがあります。 私はHBaseで多くの作業を行っていますが、メインのクライアントインターフェイスであるHTableはモックの苦痛です。ライブエンドポイントを使用するテストを記述するよりも、ユニットテストを記述するのに3〜4倍時間がかかります。 哲学的に、モックを使用するテストは、ライブエンドポイントを使用するテストよりも優先されるべきであることを知っています。しかし、HTableのモックは深刻な痛みであり、実際のHBaseインスタンスに対するテストよりも多くの利点があるとは確信していません。 私のチームの全員がワークステーションでシングルノードHBaseインスタンスを実行し、JenkinsボックスでシングルノードHBaseインスタンスを実行しているため、可用性の問題はありません。ライブエンドポイントテストは、モックを使用するテストよりも明らかに実行に時間がかかりますが、実際には気にしません。 現在、すべてのクラスに対してライブエンドポイントテストと模擬ベースのテストを作成しています。モックを捨てたいのですが、結果として品質が低下するのは望ましくありません。 皆さんはどう思いますか？
1
REST Webサービスを単体テストするにはどうすればよいですか？
ユニットテストは初めてで、DBを呼び出してDTOを設定するREST Webメソッドが1つあります。擬似コードは public object GetCustomer(int id) { CustomerDTO objCust = //get from DB return objCust; } 私の疑問は、含まれるこれらのメソッドとテストのタイプ（Integration / Unit）のテストの書き方です。単体テストの場合、DBにアクセスする必要がありますか。そうであり、顧客IDを渡してアサーションをほとんど行わない場合、データが最終的に変更されて失敗する可能性があります。 ここでこれらの概念を理解している何かが欠けていると思います。
2
ソフトウェアテストの手法またはカテゴリ[非公開]
ここで何が尋ねられているかを伝えるのは難しいです。この質問は曖昧、曖昧、不完全、過度に広範、または修辞的であり、現在の形式では合理的に答えることができません。この質問を明確にして、再開できるようにするには、ヘルプセンターに アクセスしてください。 8年前に閉鎖されました。 どのようなソフトウェアテストを知っていますか？テスト駆動開発、単体テストなどについて聞いたことがありますが、それらの重要性と違いを理解できません。たとえば、なぜ回帰テストや受け入れテストを使用するのでしょうか。彼らが提供する利点は何ですか？
2
統合テストを削除するのに十分な単体テストのカバレッジがあるかどうかを知るにはどうすればよいですか？
私はレガシーシステムで作業しています（つまり、テストなしで作成されたという意味です）。外部から機能をテストする統合テストを作成して、システムの一部をテストしようとしました。 これにより、コードの破損を心配することなく、コードの一部をリファクタリングする自信が得られます。しかし、問題は、これらの統合テストを実行するのに2分以上かかり、数分かかることです。また、それらは維持するのが苦痛です。それらはそれぞれ数千行のコードをカバーしており、そのうちの1つが壊れた場合、その理由をデバッグするのに1時間かかることがあります。 私は最近行ったこれらの機能変更のために多くの単体テストを書いてきましたが、コミットする前に常に新しいデプロイを行い、すべての統合テストを実行します。この時点で、ユニットテストと統合テストの一部がテスト内容と重複していることがわかりました。 統合テストを削除できるように、適切な単体テストが不適切な統合テストを適切にカバーしていることをどのようにして知ることができますか？
5
スケーラブルで副作用のない統合テストを作成する方法は？
私の現在のプロジェクトでは、副作用のないスケーラブルな統合テストを作成するための優れたソリューションを思いつくのに苦労しています。副作用のないプロパティに関する少しの明確化：それはほとんどデータベースに関するものです。テストが完了した後、データベースに変更が加えられるべきではありません（状態は保持されるべきです）。スケーラビリティと状態保存は一緒にならないかもしれませんが、私は本当にもっと良い解決策を求めています。 一般的な統合テストを次に示します（これらのテストはデータベース層に影響を与えます）： public class OrderTests { List<Order> ordersToDelete = new ArrayList<Order>(); public testOrderCreation() { Order order = new Order(); assertTrue(order.save()); orderToDelete.add(order); } public testOrderComparison() { Order order = new Order(); Order order2 = new Order(); assertFalse(order.isEqual(order2); orderToDelete.add(order); orderToDelete.add(order2); } // More tests public teardown() { for(Order order : ordersToDelete) order.delete(); …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.