5

私はBraintreeAPIfor .NETを使用して、支払いの処理を処理しています。彼らのビジネスは支払いをうまく処理し、APIラッパーは簡単に使用できます。ただし、提供されたAPIラッパーは、綿密な調査またはより厳密な使用によりすぐに失敗し始めます。たとえば、手巻きenumのが含まれています。私の問題は、このラッパーを使用するコードの単体テストにあります。

これを行うには、基本的に、いくつかの既知の値を含む独自の「偽の」Braintreeゲートウェイをモックアップし、要求されたときにエラーを生成する必要があります。攻撃の計画は、BraintreeAPIラッパーの機能をオーバーライドすることでした。リクエストをローカルのメモリ内エンドポイントに再ルーティングします。次に、依存性注入を使用して、実行時に適切なゲートウェイ/ラッパーをリンクできます。

当初、それは順調に進んでいるように見えました。APIラッパーでコミットされたソフトウェアエンジニアリングに対する罪にもかかわらず、オーバーライドする必要のあるすべてのメソッドが奇跡的にマークされvirtualました。しかし、それはひどく止まりました。APIラッパーのほとんどのコンストラクターはマークされていますinternal。そのため、これらのクラスを継承することも、テスト用に保存するために気まぐれに作成することもできません。

余談ですが、私はinternalコンストラクターと、それらを合法的に使用したいと思う理由を理解しています。ただし、これについてはソースコードを確認しましたが、すべてのinternalコンストラクターは簡単なプロパティの割り当てのみを実行します。そのため、私は別のコーディング慣行に従うべきだったと主張することに満足しています。

したがって、基本的に3つのオプションが残されています。

  1. 独自のAPIラッパーを最初から作成します。これは明らかに実行可能であり、適切に設計されたインフラストラクチャを生み出すという利点があります。ただし、欠点は多すぎて簡単に説明できません。

  2. APIからソースコードをプルダウンして、ソリューションに含めます。すべてのinternalコンストラクターを、それらを機能させるために必要なものに変更することができます。欠点は、後続のAPIラッパーがリリースされるたびに、これらの変更をすべて再更新する必要があることです。

  3. APIラッパー全体で使用する必要があるすべてのオブジェクトのラッパークラスを記述します。これには、提供されているソースコードを変更しないという利点があります。ただし、欠点は大きいです。基本的に、ラッパー内のすべてのクラスを3回書き換えます（インターフェイス、Braintree APIラッパーアダプター、およびテスト可能なバージョン）。

残念ながら、それらのすべてはひどいです。オプション2はオプションの中で最も悪いとは思えませんが、それは私を汚く感じさせます。誰かがこの問題をすでに解決した/より良い、よりテスト可能なラッパーを書いたことがありますか？そうでない場合、私は可能な行動方針を逃しましたか？そうでない場合、これら3つのオプションのどれが最も不快に思われますか？

4

2 に答える 2

1

おそらく、このstackoverflowエントリが役立つ可能性があります

また、このテーマに関するランダムなブログエントリ

于 2012-02-07T18:19:19.150 に答える
1

あなたは彼らのAPIをテストしていないので、私はファサードパターンを使用します。それらが提供するすべてをラップする必要はなく、使用している機能をカプセル化するだけです。これには利点もあります。将来そのAPIを廃止することにした場合は、ラッパーを再実装するだけで済みます。

于 2012-02-07T22:10:22.473 に答える