Jersey e2e Integrationstests für In-Memory-Datenbank mit Spring JDBCTemplate

Question

Was ist die richtige Art und Weise der Erstellung und Ausführung von e2e Integrationstests für Jersey REST API, die jersey-test-framework-provider-inmemory, h2-Datenbank und org.springframework.jdbc.core.JdbcTemplate verwendet?

Anforderungen:

Der Prüfumfang sollte End-to-End sein: von Ressource beginnen und zur h2-Datenbank über alle Anwendungen geht.

Writing Tests:

Derzeit meine JUnit Integrationstests schlagen fehl, wenn alle zusammen von IDE JUnit ausführen, vor allem, weil sie sich gegenseitig stören (gleichzeitig mit JUnit ausgeführt wird). Ein weiteres Problem ist, dass nach jedem Test ein Rollback durchgeführt werden sollte, verwenden Sie die Transaktionsunterstützung (derzeit hilft @Transactional Annotation nichts zu helfen). Was ist der minimale Satz an Spring-Tools, die für diese Art von Tests benötigt werden? Wie funktioniert es? Sollte @Transactional irgendwo anders platziert werden?

Beispiel:

@Transactional 
public class OrderResourceIT extends JerseyTest { 

    @Override 
    protected Application configure() { 
     // config 
    } 

    @Override 
    protected void configureClient(final ClientConfig config) { 
     // config 
    } 

    @Before 
    public void startUp(){ 
     // database bootstrap programmatically before each test 
    } 


    @Test 
    @Transactional 
    public void testGetOrders(){ 
     Response response = target("/orders") 
       .request() 
       .get(); 

     List<Order> orders = response.readEntity(new GenericType<List<Order>>(){}); 

     // asserts 
    } 
} 

Ausführung:

Vorgesehen ist mit maven-failsafe-plugin auszuführen:

Failsafe Plugin documentation schlägt Bindung Ausgang des Behälters zu pre-integration-test phase und post-integration-test am Behälter Termination. Wie kann es konfiguriert werden, wenn mein jersey-container-grizzly2-http Container programmgesteuert konfiguriert ist? Example:

public class Main { 
    // Base URI the Grizzly HTTP server will listen on 
    public static final String BASE_URI = "http://localhost:8080/myapp/"; 

    public static HttpServer startServer() { 
     // create a resource config that scans for JAX-RS resources and providers 
     // in com.example.rest package 
     final ResourceConfig rc = new ResourceConfig().packages("com.example.rest"); 

     // create and start a new instance of grizzly http server 
     // exposing the Jersey application at BASE_URI 
     return GrizzlyHttpServerFactory.createHttpServer(URI.create(BASE_URI), rc); 
    } 

    public static void main(String[] args) throws IOException { 
     final HttpServer server = startServer(); 
     System.out.println(String.format("Jersey app started with WADL available at " 
       + "%sapplication.wadl\nHit enter to stop it...", BASE_URI)); 
     System.in.read(); 
     server.stop(); 
    } 
} 

wäre perfekt Beispielcode zu sehen arbeiten.

Answer 1

Ich denke, dass Ihr Szenario eine gute Passform für dbunit Tests ist. Mit dbunits wird für jeden auszuführenden Testfall eine speicherinterne Datenbank erstellt, die nach Abschluss der Testfallausführung gelöscht wird. Das Datenmodell dieser Datenbank hängt vollständig von der von Ihnen konfigurierten Datenmenge xml ab. Sehen Sie sich dies an: http://archive.oreilly.com/pub/post/dbunit_made_easy.html

Answer 2

Hallo, es gibt reichlich Beispiele von Jersey als Jersey-Beispiele zur Verfügung gestellt. Es gibt eine Reihe von Junit-Testfällen für jedes Modul, das den Restdienst anbietet.

Das Beispiel kann von Jersey Download-Seite heruntergeladen werden. https://jersey.java.net/download.html

Genaue Links sind unten angegeben, die sich in Zukunft ändern können.

Für alle verfügbare Version:

http://repo1.maven.org/maven2/org/glassfish/jersey/bundles/jersey-examples

Für aktuelle neueste Version:

http://repo1.maven.org/maven2/org/glassfish/jersey/bundles/jersey-examples/2.23.1/jersey-examples-2.23.1-all.zip