Test di integrazione e2e Jersey per database in memoria utilizzando Spring's JDBCTemplate

Question

Qual è il modo corretto di progettare ed eseguire test di integrazione di e2e per l'API REST di Jersey che utilizza jersey-test-framework-provider-inmemory, database h2 e org.springframework.jdbc.core.JdbcTemplate?

Requisiti:

L'ambito test deve essere end-to-end: a partire da risorse e passando attraverso tutte le applicazioni al database h2.

test di scrittura:

Attualmente il mio test di integrazione JUnit fallire se corrono tutti insieme da JUnit di IDE, soprattutto perché interferiscono con l'altro (in esecuzione in concomitanza con JUnit). Un altro problema è che dovrebbero essere ripristinati dopo ogni test, utilizzare il supporto per le transazioni (attualmente l'annotazione @Transactional non aiuta). Qual è il set minimo di strumenti di Spring necessari per supportare questo tipo di test? Come farlo funzionare? Dovrebbe essere posizionato @Transactional altrove?

Esempio:

@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 
    } 
} 

Esecuzione:

Si prevede di eseguire con maven-failsafe-plugin:

Failsafe Plugin documentation suggerisce legame iniziale del contenitore pre-integration-test phase e post-integration-test al termine contenitore. Come può essere configurato se il mio contenitore jersey-container-grizzly2-http è configurato a livello di programmazione? 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(); 
    } 
} 

sarebbe perfetto per vedere lavorare codice di esempio.

Answer 1

Penso che il tuo scenario sia perfetto per il test di dbunit. Con dbunits, un database in memoria viene generato per ogni caso di test da eseguire e viene distrutto al completamento dell'esecuzione del test case. Il modello dati di questo database dipende interamente dal dataset xml che si configura. Date un'occhiata a questo: http://archive.oreilly.com/pub/post/dbunit_made_easy.html

Answer 2

Ciao ci sono molti esempi forniti dalla maglia come esempi di jersey. Ci sono serie di test di junit per ogni modulo che ospita i servizi di resto.

L'esempio può essere scaricato dalla pagina di download della jersey. https://jersey.java.net/download.html

I collegamenti esatti sono indicati di seguito che potrebbero cambiare in futuro.

Per tutte le versioni disponibili:

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

Per corrente ultima versione:

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