外部サービスを呼び出す API に関連付けるプロジェクトに取り組んでいます。順調に進んでいますが、本格的なテストを開始する必要があります。楽しい部分？このサービスへの呼び出しの大部分は、API 内の 1 つの巨大なクラス (これを Mastadon.class と呼びます。適切だと思われます) を経由します。Mastadon には、あらゆる種類の異なる呼び出しを行うための膨大な数のメソッドがあり、私たちのプロジェクトはそれらのかなりの数を使用しています。それらの多くは、物事をプライベートなものにバウンスするパブリックな便利なメソッドですが、その数は依然としてかなり多いです。
だから今、テストの楽しみが来ます。このサービスを頻繁に呼び出すことは絶対に避けたいと思います。一部のテストでは、相手側で特定のアクションを実行し、特定のアクション/結果をサービスから送り返す必要さえありますが、これは手動で行うか、相手側で高度な自動化作業を行う必要がありますが、これは望ましくありません。行う。
Mastadon クラスのモックの子クラスを作成することもできますが、それにはスタブ化するメソッドが多数あり、テストと入力に応じてさまざまな動作が必要になる可能性があります。それはたくさんのいじわるです。モック フレームワークを使用することもできますが (現在、いくつかの目的で JMockit を使用しています)、繰り返しますが、それはサービスの多くの嘲笑であり、モックは本当に首の痛みになる可能性があります。また、私たちのコードと Mastadon クラスの仲介者として機能する注入可能なプロキシ クラス (ここで探している正確なフレーズではないかもしれませんが、アイデアは得られます) を作成するために、少し改造することも検討しました。 . 私たちのコードは実際に Mastadon に触れることはありません。代わりに、MastadonProxy などを使用して呼び出しを渡します。これは、プロジェクトの再編成とさらなる作業を意味します。しかし、MastadonTestProxy を構築し、そこに必要なものだけをスタブ化できるため、長期的にはより簡単になる可能性があります。特に親の Mastadon メソッドをテストする必要がないため、単純に親の Mastadon メソッドを参照する無数のメソッドを持つ MastadonTest クラスよりもはるかに面倒ではありません。
何て言う？この API は、テストを念頭に置いて構築されていないようです。全体のソース コードはありますが、できることなら変更を加えたくないのです。私は注入可能なプロキシ クラスに傾倒していますが、特にエンド ツー エンドの統合テストに関しては、これを処理するためのより良い方法があるかもしれません。
編集: また、API には独自の便利なメソッドを持つ他のオブジェクトが多数あり、Mastadon も通過するため、プロキシ クラスが機能しない可能性があることにも気付きました。そのため、ObjectA には、裏で Mastadon の doThis() メソッドを経由することになる doThis() メソッドが含まれる場合があります。クラス拡張/モックアベニューがこれを行う唯一の方法かもしれないと考えています...
編集：別の問題。Mastadon は、別の子クラスを持つわずかに小さい抽象クラスから継承します。3 つすべてのクラスにファサードを設定する必要がありますが、実際に機能する方法でこれらすべてのクラスを適切にファサードする方法を整理する楽しみが残ります。さらに、呼び出しを渡すために、それぞれのインスタンス (または必要に応じてそれらを作成するファクトリ) を手元に保持する必要があり、いくつかの状態 (おそらくそれらの変数の変更など) が必要になります。