Dropwizard/Jersey - テスト実行時のパブリックメソッドの依存関係がありません

Question

Dropwizardを使用してresourceTestを実行すると「Missing dependency」例外が発生しました：0.6.1（ジャージ1.15）

私のテストファイル：

public class MyResourceImplTest extends ResourceTest { 
    ........ 
    @Override 
    protected void setUpResources() throws Exception { 
     addResource(new MyResourceImpl(new myConfiguration())); 
    } 
} 

例外：

Dec 13, 2012 2:10:41 PM com.sun.jersey.test.framework.spi.container.inmemory.InMemoryTestContainerFactory$InMemoryTestContainer <init> 
INFO: Creating low level InMemory test container configured at the base URI http://localhost:9998/ 
Dec 13, 2012 2:10:42 PM com.sun.jersey.test.framework.spi.container.inmemory.InMemoryTestContainerFactory$InMemoryTestContainer start 
INFO: Starting low level InMemory test container 
Dec 13, 2012 2:10:42 PM com.sun.jersey.server.impl.application.WebApplicationImpl _initiate 
INFO: Initiating Jersey application, version 'Jersey: 1.15 10/30/2012 02:40 PM' 
Dec 13, 2012 2:10:42 PM com.sun.jersey.spi.inject.Errors processErrorMessages 
SEVERE: The following errors and warnings have been detected with resource and/or provider classes: 
    SEVERE: Missing dependency for method public javax.ws.rs.core.StreamingOutput com.****************.********(javax.servlet.http.HttpServletRequest,java.lang.String,java.lang.String) at parameter at index 0 
Dec 13, 2012 2:10:42 PM com.sun.jersey.test.framework.spi.container.inmemory.InMemoryTestContainerFactory$InMemoryTestContainer stop 
INFO: Stopping low level InMemory test container 

Answer 1

私の問題は、InMemoryコンテナでサポートされているHttpServletRequestを注入しました。この場合、テストのcontatinerとしてjetty grizzlyWebTestContainerまたはjettyを使用する必要があります。 jersey-test-framework-grizzlyを導入すると、dropwizard自体に対して多くの依存関係の競合が発生していたので、私はそれを達成できませんでした。私は、今後dropwizardをアップグレードするときに再び起こる可能性があるので、すべての競合を解決しようとする価値はないと考えています。

私は結局、私のWebサービスをテストするためにいくつかの統合テスト（pythonで）を使ってjenkinsの仕事をしました。例えば。デプロイメントの後、いくつかのhttp要求で起動し、応答コードと応答内容を確認します。はるかに簡単に判明しました。

Answer 2

はジャージーのように見えるがHttpServletRequest

が設定され、あなたのエンドポイントの1つです注入することができませんこのような？

public StreamingOutput something(@Context HttpServletRequest request, String a, String b) {} 

もしそうなら、あなたはあなたのデザインを再考したい、とクリーンなアプローチをもたらす可能性が

@Context 
private HttpContext context; 

public StreamingOutput something(String a, String b) { 

    System.out.println("Request info "+context.getRequest().getAbsolutePath()); 

} 

のために代わりに選ぶことができます。 Classリソース登録に依存している限り、リクエストごとに新しいインスタンスが保証され、スレッドの問題を回避する必要があります。

Answer 3

私がこの問題を回避する方法は、コンテキストを注入しないで抽象的なベースクラスのリソースを定義し、実際のサービス用に小さな派生クラスを実装することでした。

@Path("/contextMethod") 
@Produces(MediaType.APPLICATION_JSON) 
@Consumes(MediaType.APPLICATION_JSON) 
public class MyResourceWithContext extends BaseResource { 
    @Context 
    private HttpServletRequest request; 

    protected String getUserID() 
    { 
     return request.getRemoteUser(); 
    } 
} 

テストを実行するときは、HttpServletRequestを使用しないテスト専用の代替派生クラスを実装します。ここでの優位性は、派生したテスト可能クラスがコンテキストのハードコーディングされた値を差し込み（ある意味で）適切なテストシナリオを作成できるということです。