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

私は次のシステムで作業しています： Network Data Feed -> Third Party Nio Library -> My Objects via adapter pattern 最近、使用しているライブラリのバージョンを更新したときに問題が発生しました。これにより、とりわけ、タイムスタンプ（サードパーティライブラリがとして返すlong）がエポック後のミリ秒からエポック後のナノ秒に変更されました。 問題： サードパーティのライブラリのオブジェクトを模擬するテストを作成する場合、サードパーティのライブラリのオブジェクトについて間違えた場合、テストは間違っています。たとえば、タイムスタンプの精度が変更され、モックが間違ったデータを返したため、ユニットテストを変更する必要があることに気づきませんでした。これはライブラリのバグではありません。ドキュメントの何かを見逃したために発生しました。 問題は、実際のデータフィードがないと実際のデータ構造を生成できないため、これらのデータ構造に含まれるデータについて確信を持てないことです。これらのオブジェクトは大きくて複雑で、多くの異なるデータが含まれています。サードパーティライブラリのドキュメントは貧弱です。 質問： この動作をテストするためにテストを設定するにはどうすればよいですか？テスト自体は簡単に間違っている可能性があるため、この問題を単体テストで解決できるかどうかはわかりません。さらに、統合システムは大きく複雑であり、見落としがちです。たとえば、上記の状況では、タイムスタンプの処理をいくつかの場所で正しく調整していましたが、そのうちの1つが見つかりませんでした。システムはほとんど統合テストで正しいことを行っているように見えましたが、本番環境（より多くのデータがある）に展開すると、問題が明らかになりました。 現在、統合テストのプロセスがありません。テストは基本的に、ユニットテストを適切な状態に保ち、問題が発生したときにさらにテストを追加し、テストサーバーに展開して問題が正しかったことを確認してから、運用環境に展開します。モックが間違って作成されたため、このタイムスタンプの問題は単体テストに合格し、すぐに明らかな問題を引き起こさなかったため統合テストに合格しました。QA部門がありません。

34 testing  object-oriented-design  development-process  mocking  adapter 

特定の量の明確に定義された機能を備えたインターフェイスがあります。まあ言ってみれば： interface BakeryInterface { public function createCookies(); public function createIceCream(); } これはインターフェイスのほとんどの実装でうまく機能しますが、いくつかのインスタンスでは、いくつかの新しい機能を追加する必要があります（新しいメソッドにロールインするなどcreateBrownies()）。これを行うための明白/単純なアプローチは、インターフェースを拡張することです。 interface BrownieBakeryInterface extends BakeryInterface { public function createBrownies(); } しかし、既存のAPIを変更せずに新しい機能を追加できないという点でかなり大きな欠点があります（新しいインターフェイスを使用するようにクラスを変更するなど）。 インスタンス化後に機能を追加するためにアダプターを使用することを考えていました。 class BrownieAdapter { private brownieBakery; public function construct(BakeryInterface bakery) { this->brownieBakery = bakery; } public function createBrownies() { /* ... */ } } これは私に次のようになります： bakery = new …

25 object-oriented  design-patterns  adapter 

私は、開発中のAPIクライアントライブラリを単体テストするための最良の方法を見つけようとして、一周して回りました。このライブラリには、Client基本的にAPIとの1：1マッピングを持つWrapperクラスと、の上部でよりユーザーフレンドリーなインターフェイスを提供する追加のクラスがありますClient。 Wrapper --> Client --> External API 私は最初の両方に対してテストの束を書いたClientし、Wrapper効果的にちょうど彼らが前方（上で動作するものは何でもの適切な機能にそのことをテストし、Wrapper上の動作Client、およびClientHTTP接続で動作します）。しかし、インターフェイスではなくこれらのクラスの実装をテストしているように感じるので、これに不快感を覚え始めました。理論的には、クラスを別の完全に有効な実装に変更することはできましたが、呼び出されると予想されていた関数が呼び出されていないため、テストは失敗します。それは私にとって脆弱なテストのように聞こえます。 この後、クラスのインターフェースについて考えました。テストでは、クラスが実際に行う方法ではなく、クラスが実際に意図したジョブを実行することを確認する必要があります。どうすればこれを行うことができますか？最初に頭に浮かぶのは、外部APIリクエストをスタブ化することです。しかし、私は外部サービスを単純​​化しすぎることに神経質です。私が見たスタブAPIの例の多くは、定型応答を提供しているだけです。これは、コードが偽のAPIに対して正しく実行されることをテストするだけの非常に簡単な方法のようです。別の方法はサービスをモックすることです。これは実行不可能であり、実際のサービスが変更されるたびに最新の状態に維持する必要があります。 最後に、私はこれを に、プログラマーSEに関する別の回答ました。 リモートAPIクライアントの仕事は、特定の呼び出しを発行することです-これ以上でもそれ以下でもありません。したがって、そのテストでは、これらの呼び出しを発行することを確認する必要があります-これ以上でもそれ以下でもありません。 そして今、私は多かれ少なかれ確信しています-テストするとき、テストClientする必要があるのは、APIへの正しいリクエストを行うことだけです（もちろん、APIが変更される可能性は常にありますが、私のテストは合格し続けます-しかしそれは統合テストが役立つ場合）。以来Clientちょうど1：APIと1のマッピング、私の懸念は実際には適用されません別の有効な実装から変更について前に-の各メソッドの唯一の有効な実装がありますClient。 しかし、私はまだにこだわっています Wrapperクラスにます。次のオプションが表示されます。 Clientクラスをスタブ化し、適切なメソッドが呼び出されることをテストします。このように、私は上記と同じClientことをしていますが、APIの代用として扱います。これは私が始めたところに私をすぐに戻します。繰り返しになりますが、これはインターフェースではなく実装のテストの不快感を与えてくれます。のWrapper非常によく、完全に別のクライアントを使用して実施することができます。 モックを作成しますClient。ここで、モックを作成する方法を決定する必要があります。サービスの完全なモックを作成するには、多くの労力が必要になります（ライブラリ自体に行った以上の作業）。API自体はシンプルですが、サービスは非常に複雑です（基本的に、そのデータに対する操作を備えたデータストアです）。そして再び、私は私のモックを本物と同期させておく必要がありますClientます。 適切なHTTPリクエストが行われていることをテストするだけです。これはWrapper、実際のClientそれらのHTTP要求を行うためにオブジェクトをため、実際に個別にテストするわけではありません。これは少しひどい単体テストになります。 したがって、これらのソリューションのいずれにも特に満足していません。あなたならどうしますか？これについて正しい方法はありますか？

14 unit-testing  testing  api  mocking  adapter