メソッド内部の静的呼び出しによるJavaユニットテストの設計

Question

私は、ApacheのFluent-hcライブラリ（http://hc.apache.org/httpcomponents-client-ga/fluent-hc/apidocs/org/apache/http/client/fluent/Request.html）からRequest.Postメソッドを使用するメソッドを持つクラスの単体テストを作成しようとしています。

テストスーツを実行するたびに実際のリクエストを送信したくないということは、単体テストの場合であっても統合テストであっても、それほど少なくありません。しかし、私はその周りに自分の道を作る方法を知らない。

私はテストの世界では新しく、何かをテストできない時代の大部分を読んだことのために、クラスのデザインに問題があります。

public class HttpRequestSenderServiceImpl implements RequestSenderService { 

@Override 
public Response sendRequest(String address, String messageBody) throws IOException { 
    Request request = Request.Post(address).bodyString(messageBody, ContentType.APPLICATION_JSON); 
    Response response = request.execute(); 

    return response; 
} 

}

Iは、テストツールとしてSpringフレームワークとSpringテスト、MockitoとTestNGのを使用しています。私は本当にあなたが正しい方向に、指導することができれば、本当に感謝します。私はちょうどそれを正しい方法でやることを学びたいと思う。

私は問題にいくつかの "解決策"を見つけましたが、すべてPowerMockitoを使用しています。私が読んだことは悪いコーディング方法に変換する静的メソッド、コンストラクタなどをモックできるためです。私がここで避けようとしているものです。

Answer 1

あなたの目的のために、問題は、あなたのコードよりも、静的でモックフレンドリーではない、流動性の高いhc Request.Postにあります。

あなたはExecutor使用することができますし、モックメソッドを実行するか、Request.Postを使用したい場合は、それを別の低レベルのサービス・インターフェースでラップして使用します。

interface RequestSender { 
     Response send(String addr,msgBody) 
} 

class RequestSenderImpl implements RequestSender { 
    public Response send(String addr,msgBody) { 
     Request request = Request.Post(address).bodyString(messageBody,ContentType.APPLICATION_JSON); 
     Response response = request.execute(); 
     return response; 
    } 
} 

こうすることで、簡単にでもmockitoせずにコードを模擬することができます。

Answer 2

@lujopは、私がそれを行う一つの方法だと言われている問題についての示唆を提供しています。

しかし、モッキングフレームワークを使用する以前の記述では、私はまったく悪い習慣ではありません。 @lujopからの提案を考えてみましょう。おそらく、を使用してRequestSenderImplのユニットテストとそのビジネスロジックを完成させるでしょう。

しかし、実際にRequest.Postを呼び出すのは、FluentHCRequestSenderというクラスがあります。今度はすべてのクラスのUTを作成している場合は、このクラスが適切なAPIを使用していることを確認するために、模擬フレームワークを使用してFluentHCRequestSenderをテストする必要があります。

モッキングフレームワークを使用したテスト用の場所があります。しかし、あなた、あなたのチーム、またはあなたの組織が作成したクラスがあなたの依存関係である場合には、モックフレームワークを使用してしまうと、悪い設計を指しているだけです。

、一般的に、より良いUTとコードを書くのお手伝いをすることができ、リソースのあなたの質問に答えるために、

SOLID principles - これはおそらく、コードを書きながら、バック 私の心の中に常にある一つのことです。

Working Effectively with Legacy Code私によく役立っています。

Test Driven Development - 私の練習中に、非常に簡単 に厳密にあなたの毎日のルーチンに従っていないが、それは、少なくとも私のUTをオフ入れて、私の実際の クラスと同時にそれらに動作しない 私を強制的に（前になければ）。

Design Patterns - ライブラリがあなたにアクセスしたり、購入することができれば、良いデザインパターンブック/ビデオ をつかんでください。概念は のように思えるかもしれませんが、私はそれらのうちのいくつかが私の日常的な仕事で、特にUTを書いている間は本当に役に立ちました。

しかし、個人的には、コードベースの既存のコードを見て、良いものと改善できるものを見ることを学ぶ最も良い方法です。私は、良いデザインをしている人が書いたコードを見て理解していることが分かっています。

この長い巻き取りポストが役立ちますように！

PS - 正しい方法を実行しようとしています。時にはそれはすべきだが、しばしば言われていない。