タグ付けされた質問 「mocking」

TDDについて多くのことを読みましたが、まだ疑問があります。たとえば、次のクラス図があります。 これは、TDDとモックオブジェクトについて学ぶための簡単な例です。 どのテストを最初に書くべきですか？製品、次にライン、最後に注文？その場合、ラインと製品を使用して注文をテストする必要がありますか、またはモックオブジェクトを使用する必要がありますか？モックオブジェクトはいつ使用する必要がありますか？XPおよびTDDでUMLを使用する必要がありますか？ 私はまだこれらのものを得ていません。

14 php  unit-testing  tdd  mocking 

私は画像処理（主にOCR）に取り組んでおり、開発に単体テストをどのように統合すべきか疑問に思っています。 私はすでに、より一般的なタイプのコードに対して単体テストを使用していますが、画像処理コードを処理するとき、その処理方法がわかりません。この種のコードには常に画像データの入出力が必要であり、これを模倣することは明らかではありません。今のところ、主に統合テストを行っていますが、実行には時間がかかります。この種のコードをユニットテストに分割して、より迅速に実行できるようにするためのアイデアが欲しいです。 編集：キャラクターの分析は、複数の回転、スケーリング、および形態学的操作を含む多くのステップを経ることができます。これらの手順は、アルゴリズムの開発中に頻繁に変更されます。したがって、テスト中に入力と期待される出力は大きく変化する可能性があります。各文字は100x100ピクセルにすることができるため、コード内でハードコーディングしたり、生成されたデータを操作したりするのは問題ありません。

14 testing  unit-testing  tdd  integration-tests  mocking 

Amazon S3にドキュメントをアップロードするメソッドのテストに苦労していますが、この質問は重要なAPI /外部の依存関係に当てはまると思います。考えられる解決策は3つしかありませんが、満足できるものはありません。 コードを実行し、実際にドキュメントをアップロードし、AWSのAPIでアップロードされたことを確認し、テストの終了時に削除します。これにより、テストが非常に遅くなり、テストを実行するたびに費用がかかり、常に同じ結果が返されません。 モックS3。私はそのオブジェクトの内部についてはまったくわからないので、これは非常に毛深いです。 MyObject.upload（）が正しい引数で呼び出されることを確認し、S3オブジェクトを正しく使用していることを信頼してください。テストだけではS3 APIを正しく使用したかどうかを確実に知る方法がないため、これは気になります。 Amazonが独自のSDKをテストし、彼らがすべてを模擬する方法を確認しました。彼らは、モックを行う200行のヘルパーを持っています。私が同じことをするのが実際的だとは思わない。 これをどうやって解決しますか？

13 testing  mocking 

少し前に、私は見つけることができないStack Overflowの回答で、パブリックAPIをテストする必要があることを説明した文を読み、著者はインターフェイスをテストする必要があると言いました。また、メソッドの実装が変更された場合、テストケースを変更する必要はありません。これを行うと、テスト中のシステムが機能することを確認する契約が破られるため、著者は説明しました。つまり、メソッドが機能しない場合はテストが失敗しますが、実装が変更されたためではありません。 私たちがock笑について話すとき、これは私の注意を呼びました。モックはテスト対象システムの依存関係からの期待呼び出しに大きく依存しているため、モックはインターフェイスではなく実装と密接に結合されています。 モックとスタブの調査中、いくつかの記事は、依存関係からの期待に依存しないため、モックの代わりにスタブを使用する必要があることに同意しています。 私の質問は次のとおりです。 モックはオープン/クローズの原則に違反しますか？ 最後の段落のスタブを支持する議論に欠けているものはありますか？ もしそうなら、いつスモックを作成するのに適したユースケースになり、スタブを使用するのに適したユースケースになりますか？

13 unit-testing  solid  mocking  open-close  stub 

私は複数のレイヤーを持つアプリケーションに取り組んでいます。データソースからデータを取得して保存するデータアクセスレイヤー、データを操作するビジネスロジック、画面にデータを表示するユーザーインターフェイス。 ビジネスロジックレイヤーの単体テストも行っています。唯一の要件は、ビジネスレイヤロジックのフローをテストすることです。そこで、Moqフレームワークを使用してデータアクセスレイヤーをモックし、MS Unitでビジネスロジックレイヤーを単体テストします。 インターフェイスプログラミングを使用して、ユニットテストを実行できるように、設計を可能な限り分離します。インターフェイスを介したビジネスレイヤコールデータアクセスレイヤ。 ビジネスロジックメソッドの1つをテストしようとすると、問題に直面しています。このメソッドはいくつかの作業を行い、オブジェクトを作成してデータアクセスレイヤーに渡します。そのデータアクセスレイヤーメソッドをモックしようとすると、正常にモックできません。 ここでは、問題を示すデモコードを作成しようとしています。 モデル： public class Employee { public string Name { get; set; } } データアクセス層： public interface IDal { string GetMessage(Employee emp); } public class Dal : IDal { public string GetMessage(Employee emp) { // Doing some data source access work... return string.Format("Hello {0}", emp.Name); …

11 unit-testing  mocking 

私は、「Growing Object-Oriented Software」の本の抜粋を読んだところです。これは、具象クラスのモックが推奨されない理由を説明しています。 以下に、MusicCentreクラスの単体テストのサンプルコードを示します。 public class MusicCentreTest { @Test public void startsCdPlayerAtTimeRequested() { final MutableTime scheduledTime = new MutableTime(); CdPlayer player = new CdPlayer() { @Override public void scheduleToStartAt(Time startTime) { scheduledTime.set(startTime); } } MusicCentre centre = new MusicCentre(player); centre.startMediaAt(LATER); assertEquals(LATER, scheduledTime.get()); } } そして彼の最初の説明： このアプローチの問題は、オブジェクト間の関係が暗黙的に残されることです。モックオブジェクトを使用したテスト駆動開発の目的は、オブジェクト間の関係を発見することであることを明確にしたことを願っています。サブクラスを作成する場合、ドメインコードにはそのような関係を表示するものはなく、オブジェクトのメソッドだけです。これにより、この関係をサポートするサービスが他の場所に関連しているかどうかを確認するのが難しくなり、次回クラスで作業するときに分析をやり直す必要があります。 彼が言うとき、彼が何を意味するのか正確に理解することはできません。 これにより、この関係をサポートするサービスが他の場所に関連しているかどうかを確認するのが難しくなり、次回クラスで作業するときに分析をやり直す必要があります。 サービスはMusicCentreのメソッドに対応することを理解していますstartMediaAt。 「他の場所」とはどういう意味ですか？ …

11 java  object-oriented  unit-testing  mocking  junit 

テストを書くとき、誰かがデータをモックするだけでなくインメモリデータベースを使用したいのはなぜですか？ インメモリデータベースは、自分のリポジトリをテストするのに役立つことがわかりました。ただし、フレームワーク（Spring Dataなど）を利用する場合、リポジトリのテストはフレームワークのテストであり、実際にはアプリケーションロジックではありません。 ただし、モッキングはより高速に見え、単体テストやTDDを作成するときに一般的に採用されているのと同じパターンに従っています。 それで私は何が欠けていますか？インメモリデータベースが役立つのはいつ/なぜですか？

11 unit-testing  testing  tdd  mocking 

「依存する」と確信しているので、冗談めかして質問にタイトルを付けましたが、特定の質問があります。 多くの依存関係の深い層を持つソフトウェアで作業している私のチームは、モックをかなり広範囲に使用して、各コードモジュールをその下の依存関係から分離することに慣れています。 したがって、このビデオでロイ・オセロベが5％程度の時間だけモックを使用すべきであると示唆していることに驚きました。私たちは70-90％のどこかに座っていると思います。他の同様のガイダンスも時々見ました。 私は「統合テスト」の2つのカテゴリーと見なすものを定義する必要があります。これらは非常に異なるため、実際には異なる名前を付ける必要があります。1）複数のコードモジュールを統合するインプロセステストと2）話し合うアウトプロセステストデータベース、ファイルシステム、Webサービスなどに対応しています。私が関心を持っているのはタイプ1で、複数のコードモジュールをすべてインプロセスで統合するテストです。 私が読んだコミュニティガイダンスの多くは、単体テストは正確な場所に関する正確なフィードバックを提供するため、多数の分離された細粒度の単体テストと少数の粗粒度のエンドツーエンド統合テストを優先する必要があることを示唆しています回帰が作成された可能性がありますが、セットアップが面倒な大まかなテストは、実際にはシステムのエンドツーエンドの機能をより多く検証します。 このため、これらの個別のコード単位を分離するには、モッキングをかなり頻繁に使用する必要があるようです。 次のようなオブジェクトモデルがあるとします。 ...また、アプリケーションの依存関係の深さは、この画像に収められるよりもはるかに深くなるため、2〜4層と5〜13層の間に複数の層Nがあることを考慮してください。 ユニット＃1で行われている簡単な論理決定をテストする場合、およびすべての依存関係がそれに依存するコードモジュールにコンストラクター注入されている場合、たとえば、2、3、および4は、モジュール1にコンストラクター注入されます。画像では、2、3、および4のモックを1に注入するほうがはるかに便利です。 それ以外の場合は、2、3、および4の具象インスタンスを作成する必要があります。これは、追加のタイピングだけでは難しい場合があります。多くの場合、2、3、および4は、コンストラクター要件を満たし、グラフに従って（およびプロジェクトの現実に従って）、困難な場合があります。Nから13の具体的なインスタンスを構築して、 2、3、4。 この状況は、2、3、または4が特定の方法で動作して、＃1の単純な論理決定をテストできるようにする必要がある場合、より困難になります。2、3、または4が必要な動作をするようにするには、オブジェクトグラフ/ツリー全体を一度に理解し、「精神的に推論する」必要があるかもしれません。多くの場合、myMockOfModule2.Setup（x => x.GoLeftOrRight（））。Returns（new Right（））;を実行する方がはるかに簡単です。モジュール2が正しく進むように指示したときに、モジュール1が期待どおりに応答することをテストします。 2 ... N ... 13の具象インスタンスをすべて一緒にテストすると、テスト設定は非常に大きくなり、ほとんどが重複します。テストの失敗は、リグレッションの失敗の場所を正確に特定するのに非常に適しているとは限りません。テストは独立していません（別のサポートリンク）。 当然のことながら、これらのモジュールがそれ以上依存することはほとんどないため、最下層の相互作用ベースのテストではなく、状態ベースのテストを行うことは、しばしば妥当です。しかし、モジュールを一番下より上に分離するために、モッキングが定義上ほとんど必要であるようです。 このすべてを踏まえて、私が欠けているかもしれないものを誰かに教えてもらえますか？私たちのチームはモックを使いすぎていませんか？あるいは、ほとんどのアプリケーションの依存関係の層が十分に浅く、統合されたすべてのコードモジュールをテストすることが実際に合理的である（私たちのケースを「特別な」ものにする）と、通常の単体テストガイダンスに何らかの仮定があるのでしょうか。あるいは、おそらく別の方法として、私たちのチームは私たちの制限されたコンテキストを適切に制限していませんか？

10 unit-testing  mocking 

TDDの実行中に問題が発生。いくつかのテストに合格すると、一部のクラス/モジュールの戻り値の型が変わります。静的に型付けされたプログラミング言語で、以前にモックされたオブジェクトが他のクラスのテストで使用され、型の変更を反映するように変更されていない場合、コンパイルエラーが発生します。 ただし、動的言語の場合、戻り値の型の変更が検出されず、他のクラスのテストは引き続き成功します。もちろん、後で失敗するはずの統合テストがあるかもしれませんが、単体テストは誤ってパスします。これを回避する方法はありますか？ 簡単なサンプルで更新しています（一部の人工言語）... バージョン1： Calc = { doMultiply(x, y) {return x * y} } //.... more code .... // On some faraway remote code on a different file Rect = { computeArea(l, w) {return Calc.doMultipy(x*y)} } // test for Rect testComputeArea() { Calc = new Mock() Calc.expect(doMultiply, 2, 30) // …

10 unit-testing  mocking  tdd 

時々、オブジェクトは密結合される必要があるだけです。たとえば、CsvFileクラスはおそらくCsvRecordクラス（またはICsvRecordインターフェイス）と緊密に連携する必要があります。 ただし、私が過去に学んだことから、テスト駆動開発の主な理念の1つは、「一度に複数のクラスをテストしないこと」です。ICsvRecordつまり、の実際のインスタンスではなく、モックまたはスタブを使用する必要がありますCsvRecord。 しかし、このアプローチを試した後、CsvRecordクラスをモックアウトすると少し毛むくじゃらになることに気づきました。これにより、2つの結論のうちの1つに導かれます。 単体テストを書くのは難しい！それはコードの匂いです！リファクタリング！ すべての依存関係をモックアウトするのは不合理です。 モックを実際のCsvRecordインスタンスに置き換えると、状況ははるかにスムーズに進みました。他の人々の考えを探しているとき、私はこのブログ投稿を偶然見つけました。これは上記の＃2をサポートしているようです。自然に密結合されているオブジェクトの場合、モッキングについてそれほど心配する必要はありません。 私は道を外れていますか？上記の仮定2の欠点はありますか？デザインをリファクタリングすることを実際に考えるべきですか？

10 tdd  coupling  mocking 

最近のJava Magazine号のKent Beckへのインタビューから： Binstock：マイクロサービスについて説明しましょう。一部のサービスが機能するためには、他のサービスの束全体の存在が必要になるという意味で、マイクロサービスのテストファーストは複雑になるように思えます。同意しますか？ ベック：1つの大きなクラスまたはたくさんの小さなクラスを持つことについては、同じトレードオフのセットのようです。 Binstock：そうです、私が推測する場合を除いて、特定のサービスをテストできるシステムをセットアップできるようにするためには、ここでは非常に多くのモックを使用する必要があります。 ベック：そう思わない。命令型のスタイルの場合は、モックをたくさん使用する必要があります。外部依存関係がコールチェーンの上位に集められている関数型のスタイルでは、それは必要ないと思います。単体テストから多くの報道を得ることができると思います。 彼はどういう意味ですか？機能的なスタイルで、外部の依存関係をあざけることからどのように解放できますか

10 functional-programming  tdd  mocking 

いくつかの最も一般的な言語（Java、C＃、Javaなど）では、コードを完全にTDDしたいときに、その言語と対立しているように見えることがあります。 たとえば、JavaとC＃では、クラスの依存関係をモックする必要があり、ほとんどのモックフレームワークでは、クラスではなくインターフェイスをモックすることをお勧めします。これは、多くの場合、単一の実装で多くのインターフェースがあることを意味します（この影響は、TDDにより多数の小さいクラスを作成するよう強制されるため、さらに顕著になります）。具象クラスを適切にモックできるようにするソリューションは、コンパイラーを変更したり、クラスローダーをオーバーライドしたりするなど、かなり厄介です。 それで、TDDに最適になるようにゼロから設計された言語はどのようになりますか？（インターフェイスをコンストラクタに渡すのではなく）依存関係を記述する何らかの言語レベルの方法で、明示的に行うことなくクラスのインターフェイスを分離できるのでしょうか？

9 java  c#  programming-languages  tdd  mocking 

HSQLDBは素晴らしいです。また、組み込みモード（専用サーバーは不要）を備えているため、Proof of Conceptsなどの迅速なプロトタイピングが可能になり、さまざまなデータをすばやく簡単に保存できるため、本番環境ですぐに使用できるアプリケーションにも最適です。 ただし、私が過去数年取り組んできたプロジェクトの少なくとも90％は、SQLデータベースを何らかの方法で処理する場合、組み込みHSQLDBを使用するユニットテストを避けられません。 確かに、これらのプロジェクト（ほとんどの場合、標準のMaven構造を使用します）には、大量の「単体テスト」（または少なくとも、ある種のテストがありますが、「単体テスト」領域にあります）があります。いくつかのCRUD操作を実行して結果を確認するために、HSQLDBの1つ以上の埋め込みインスタンスを使用するプロジェクト（「src / test / java」など）の）。 私の質問は、これはアンチパターンですか？HSQLDBは​​簡単に統合でき、組み込みサーバーは非常に軽量であるため、実際のデータベースの「モックアップ」として見過ごされがちですが、そうでない場合はどうでしょうか。（それらのそれぞれは、「何か」で構成されているので、このようなテストは、より統合テストのように扱われるべきではないと、データベース・サーバーとの「何か」の統合という）？または、「単体テスト」定義に何か欠けているのでしょうか。このようにHSQLDBを使用すると、「単体テスト」定義の「依存関係を模擬し、単体のみをテストする」部分に固執すると言えます。

9 database  unit-testing  mocking  integration-testing 

進む この質問をする前に、SEに関する多くの関連する質問を含め、多くのことを読みました。 （ソフトウェアエンジニアリングSE）目的がわからないコードのテストを書く （ソフトウェアエンジニアリングSE）ユニットテスト初心者チームはユニットテストが必要 （ソフトウェアエンジニアリングSE）レガシーコードを自動テストで改造するためのベストプラクティス （ソフトウェアエンジニアリングSE）大規模なレガシーシステムを単体テストする方法 （ブログ投稿）単体テスト環境をモックアップする方法 しかし、助けを求めて読んだ後、かゆみはまだ引っかかれていないと感じざるを得ません。 TL; DR 実行、シミュレーション、読み取り、または簡単に理解できないレガシーコードの単体テストを作成するにはどうすればよいですか？おそらく意図したとおりに機能するコンポーネントに役立つ回帰テストは何ですか？ 全体像 私は大学院に移行しているので、再び夏の帰国研修生です。私の仕事には次の要件が含まれます。 特定の製品について、ソフトウェアチームが既存のプロジェクトとの互換性を失うことなくIDEおよびJUnitバージョンをアップグレードできるかどうかを評価します。 既存のJavaコード（主にJavaではない）の一部のコンポーネントの単体テストを開発します。ユニットテストとTDDは、使用する必要がある非常に貴重なツールであることをソフトウェアチームに納得させたいと思います。（現在、0％のコードカバレッジがあります。） どういうわけか、重要なシステムのカウボーイコーディングの時代を終わらせてください。 ソースコードのコピーを入手した後、この製品の機能と動作を理解できるように、ビルドして実行しようとしました。できませんでした。私は上司に自分のやり方を尋ね、実際に機能するビルドスクリプトを含む、それをビルドできる新しいスタンドアロンマシンを発行されました。彼らの予想通り、製品コードは設計された組み込みシステムでのみ実行されるため、それも機能しませんでした。しかし、彼らはこの目的のためにシミュレーターを持っているので、彼らはシミュレーターを手に入れ、このマシンにそれを置いてくれました。シミュレータも機能しませんでした。代わりに、私は最終的に特定の画面のGUIのプリントアウトを受け取りました。また、700,000以上のJava LOC内のどこにもコードコメントがないため、把握がさらに困難になります。さらに、彼らのプロジェクトが新しいIDEと互換性があるかどうかを評価する問題がありました。特に、彼らのコードは、彼らが使用しているまさにそのIDEバージョンに適切にロードされませんでした。 私の在庫は次のようになっています： NetBeans 8、9、10、11 JUnit 4、5 特定の製品のソースコード（700,000以上のJava LOCを含む） 実質的にコードコメントはありません（場合によっては署名） 既存のテストはありません GUIウィンドウの物理的な写真 画像内のコンポーネントについて説明していないソフトウェア設計ドキュメント（109ページ） 少なくとも理論的には実行可能なテストを書くのに十分です。そこで、このコンポーネントについて基本的な単体テストを試しました。しかし、モデル、マネージャー、DB接続など、依存関係として持つオブジェクトを初期化できませんでした。基本的な単体テスト以外にJUnitの経験はあまりないので、次のセクションに進んでください。 私の読書から学んだこと モッキング：単体テストを作成する場合、本番環境での依存関係のために、モック変数を用意する必要がありますsetUp。 ここの誰もがマイケルフェザーズの著書「レガシーコードを効果的に使用する」を寛大に提案しています。 回帰テストは、おそらく開始するのに適しています。統合テストを試すのに十分な兵器がないと思います。回帰テストは、ソフトウェアチームにすぐに満足感を与えるでしょう。ただし、私は彼らの既知のバグにアクセスできません。しかし、私はたぶん尋ねることができました。 そして今、私がまだ疑問として持っている不確実性を明確にする試み。基本的に、私はこれらのテストを作成する方法の一部を理解していません。（おそらく）上司からこれ以上のガイダンスを受け取らないと想定すると、このコンポーネントの機能を理解するだけでなく、どのテストが回帰テストとして実際に役立つかを判断するのは私の球場です。 このようなプロジェクトに携わってきた専門家として、このような状況で単体テストを作成する方法について何かアドバイスはありますか？

8 unit-testing  testing  mocking  legacy  legacy-code 

TDDの背後にあるアイデアと、チームがTDDを使用する方法を把握しようとしています。NUnit + Moqを使用した次のテストケースがあります（メモリで書き込むだけで、サンプルがコンパイルされるとは限りませんが、説明が必要です）。 [Test] public void WhenUserLogsCorrectlyIsRedirectedToLoginCorrectView() { Mock<IUserDatabaseRepository> repoMock = new Mock<IUserDatabaseRepository>(); repoMock.Setup(m => m.GetUser(It.IsAny())).Returns(new User { Name = "Peter" }); Mock<ILoginHelper> loginHelperMock = new Mock<ILoginHelper>(); loginHelperMock.Setup(m => m.Login(It.IsAny(), It.IsAny())).Returns(true); Mock<IViewModelFactory> factoryMock = new Mock<IViewModelFactory>(); factoryMock.Setup(m => m.CreateViewModel()).Returns(new LoginViewModel()); AccountController controller = new AccountController(repoMock.Object, loginHelperMock.Object, factoryMock.Object) var result = …

8 tdd  mocking