2010-11-11 36 views
3

J'écris des tests d'intégration pour tester des Routes existantes. La méthode recommandée d'obtenir la réponse ressemble à ceci (via Camel In Action section 6.4.1):Apache Camel Test d'intégration - NotifyBuilder

public class TestGetClaim extends CamelTestSupport { 

    @Produce(uri = "seda:getClaimListStart") 
    protected ProducerTemplate producer; 

    @Test 
    public void testNormalClient() { 
     NotifyBuilder notify = new NotifyBuilder(context).whenDone(1).create(); 

     producer.sendBody(new ClientRequestBean("TESTCLIENT", "Y", "A")); 
     boolean matches = notify.matches(5, TimeUnit.SECONDS); 
     assertTrue(matches); 

     BrowsableEndpoint be = context.getEndpoint("seda:getClaimListResponse", BrowsableEndpoint.class); 
     List<Exchange> list = be.getExchanges(); 
     assertEquals(1, list.size()); 
     System.out.println("***RESPONSE is type "+list.get(0).getIn().getBody().getClass().getName()); 
    } 
} 

Les séries de tests, mais je reçois rien en retour. Le assertTrue(matches) échoue après le délai de 5 secondes.

Si je réécris le test pour ressembler à ceci je reçois une réponse:

@Test 
public void testNormalClient() { 
    producer.sendBody(new ClientRequestBean("TESTCLIENT", "Y", "A")); 
    Object resp = context.createConsumerTemplate().receiveBody("seda:getClaimListResponse"); 
    System.out.println("***RESPONSE is type "+resp.getClass().getName()); 
} 

La documentation est un peu de lumière autour de ce si quelqu'un peut me dire ce que je fais mal à la première approche? Y at-il quelque chose de mal à suivre la deuxième approche à la place?

Merci.

MISE À JOUR Je brise cette baisse et il semble que le problème est avec le mélange de Seda comme critère d'évaluation de départ en combinaison avec l'utilisation d'un recipientList dans la route. J'ai également changé la construction de NotifyBuilder (j'avais le mauvais point de terminaison indiqué).

  • Si je change le point final de départ à directe au lieu de Seda le test fonctionnera; ou
  • Si je commente le recipientList alors le test fonctionnera.

Voici une version allégée de ma route qui reproduit cette question:

public class TestRouteBuilder extends RouteBuilder { 

    @Override 
    public void configure() throws Exception { 
//  from("direct:start") //works 
     from("seda:start") //doesn't work 
     .recipientList(simple("exec:GetClaimList.bat?useStderrOnEmptyStdout=true&args=${body.client}")) 
     .to("seda:finish"); 
    } 

} 

Notez que si je change le code source du NotifyTest de la "Camel En action" source avoir un constructeur d'itinéraire comme celui-ci alors il échoue également.

Répondre

2

Essayez d'utiliser « Seda: getClaimListResponse » dans le getEndpoint être sûr que le uri point final est 100% correct

+0

Merci Claus. J'ai mis à jour la question. GetClaimListRouteBuilder.responseNode est juste une méthode statique qui retourne la même chaîne. Je l'ai remplacé et relancer le test avec les mêmes résultats. – Damo

+0

Claus, j'ai identifié quelques problèmes et mis à jour ma question. Est-ce que le résultat vous semble étrange? – Damo

0

FWIW: Il semble que notifyBuilder conjointement avec les files d'attente Seda ne sont pas tout à fait de travail: une classe de test pour illustrer :

public class NotifyBuilderTest extends CamelTestSupport { 

// Try these out! 
// String inputURI = "seda:foo"; // Fails 
// String inputURI = "direct:foo"; // Passes 

@Test 
public void testNotifyBuilder() { 

    NotifyBuilder b = new NotifyBuilder(context).from(inputURI) 
      .whenExactlyCompleted(1).create(); 

    assertFalse(b.matches()); 
    template.sendBody(inputURI, "Test"); 
    assertTrue(b.matches()); 

    b.reset(); 

    assertFalse(b.matches()); 
    template.sendBody(inputURI, "Test2"); 
    assertTrue(b.matches()); 
} 

@Override 
protected RouteBuilder createRouteBuilder() throws Exception { 
    return new RouteBuilder() { 
     @Override 
     public void configure() throws Exception { 
      from(inputURI).to("mock:foo"); 
     } 
    }; 
} 
}