Dropwizard/Jersey - brak zależności dla publicznej metody podczas uruchamiania testów

Question

Napotkano wyjątek "Brak zależności" podczas korzystania z resourceTest przy użyciu Dropwizard: 0.6.1 (koszulka 1.15), czy ktoś miał doświadczenie w tej sprawie?

Mój plik testowy:

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

Wyjątek:

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

Mój problem polegał na tym, że wstrzyknąłem HttpServletRequest, który jest obsługiwany przez kontener InMemory, w tym przypadku potrzebowałbym użyć pomostu grizzlyWebTestContainer lub pomostu jako testowego rozwiązania. Nie bardzo mi się to również nie udawało, ponieważ wprowadzenie w teście testowym koszulki-grizzly spowodowało wiele konfliktów zależności od samego DropWizarda. Rozumiem, że nie warto próbować rozwiązywać wszystkich konfliktów, ponieważ kiedy uaktualniam w przyszłości program DropWizard, może się to powtórzyć.

Pod koniec dnia zakończyłem pracę z Jnkinami przy pomocy niektórych testów integracyjnych (w pythonie) w celu przetestowania moich usług internetowych. na przykład. po wdrożeniu uruchom niektóre żądania HTTP, sprawdź kod odpowiedzi i treść odpowiedzi. O wiele łatwiej.

Answer 2

Wygląda na Jersey nie jest w stanie wstrzyknąć HttpServletRequest

Jest jednym z punktów końcowych skonfigurowany lubię to?

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

Jeśli tak, to może warto przemyśleć swój projekt i wybrać zamiast do

@Context 
private HttpContext context; 

public StreamingOutput something(String a, String b) { 

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

} 

które mogą dawać czystsze podejście. Dopóki będziesz polegać na rejestracji zasobów Class, masz zagwarantowaną nową instancję na każde żądanie, które powinno unikać problemów z wątkami.

Answer 3

Sposób, w jaki to zrobiłem, polegał na zdefiniowaniu abstrakcyjnego zasobu bazowego bez wstrzykniętego kontekstu, a następnie zaimplementowania niewielkiej klasy pochodnej dla prawdziwej usługi.

@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(); 
    } 
} 

Po uruchomieniu testów, następnie wdrożyć alternatywny pochodzi klasę tylko do testowania, który nie używa HttpServletRequest. Zaletą bonusu jest to, że twoja wyprowadzona testowalna klasa może dodać (powiedzmy) zakodowaną wartość dla kontekstu, aby stworzyć odpowiednie scenariusze testowe.