Test Camel with MockEndpoints

Question

Ho una serie di componenti "pipeline" che comunicano tutti attraverso le code di messaggi ActiveMQ. Ogni componente utilizza Camel per trattare ciascuna di queste code come Endpoint. Ogni componente utilizza lo stesso schema di base:

dove ogni componente consuma messaggi fuori di una coda di input, elabora il messaggio (s), e poi mette 1+ messaggi su una coda in uscita/uscita. La coda "output" diventa quindi la coda "input" per il componente successivo nella catena. Piuttosto basico.

Attualmente sto provando a rimboccarmi le maniche e fornire un test dell'unità per ciascun componente utilizzando lo MockEndpoints fornito dall'API di test Camel. Mi sono riversato sui javadoc e sui pochi esempi sul sito Web di Camel, ma ho difficoltà a collegare tutti i punti.

Mi sembra che, per ogni componente, una parte del mio test di unità sta andando a voler realizzare le seguenti tre cose:

• di prova per vedere se ci sono messaggi in attesa su un particolare "di ingresso "coda
• Tirare giù quei messaggi ed elaborarli
• push di nuovi messaggi a un 'coda di uscita' e verificare che l'hanno fatta ci

I essere Lieve Ho bisogno di creare MockEndpoints per ogni coda in questo modo:

@EndpointInject(uri = "mock:inputQueue") 
protected MockEndpoint intputQueue; 

@EndpointInject(uri = "mock:outputQueue") 
protected MockEndpoint outputQueue; 

Così ora, nei miei metodi di prova JUnit, posso impostare le aspettative e interagire con questi endpoint:

@Test 
public final void processMethodShouldSendToOutputQueue() 
{ 
    Component comp = new Component(); 
    comp.process(); 

    outputQueue.assertIsSatisfied(); 
} 

Sono semplicemente non capire come collegare tutto correttamente:

• Come si collega comp al inputQueue e outputQueue MockEndpoints?
• Per ogni MockEndpoint, come si impostano le aspettative in modo che assertIsSatisfied() controlli che un messaggio sia presente in una determinata coda o che una determinata coda contenga messaggi?

Answer 1

Adam, ci sono diversi modi per farlo.

Per i componenti POJO, blackbox li prova separatamente da qualsiasi contesto/instradamento Camel per concentrarsi sulla logica aziendale.

Se si desidera eseguire test end-to-end dei percorsi, considerare l'utilizzo di uno di questi approcci per verificare che ogni fase del percorso sia soddisfatta.

• uso NotifyBuilder per costruire espressioni di validazione Exchange (piuttosto complesse per ottenere la testa intorno)
• uso AdviceWith per modificare dinamicamente il percorso prima la sua corsa (aggiungere Log/endpoint Mock, ecc)

Preferisco AdviceWith perché è molto flessibile e sfrutta i noti MockEndpoints. Per un esempio completo di questo, vedere this unit test

In breve, si creerà uno unit test per iniettare MockEndpoints nel vostro percorso e quindi convalidare contro di loro come al solito ...

context.getRouteDefinition("myRouteId").adviceWith(context, new AdviceWithRouteBuilder() { 
    @Override 
    public void configure() throws Exception { 
     // mock all endpoints 
     mockEndpoints(); 
    } 
}); 

getMockEndpoint("mock:direct:start").expectedBodiesReceived("Hello World"); 

template.sendBody("direct:start", "Hello World");