[CONF] Apache Camel: Testing (page edited)

[confluence]

Page Edited : CAMEL : Testing Testing has been edited by James Strachan (Dec 03, 2008). (View changes) Content: Testing Testing is a crucial activity in any piece of software development or integration. Typically Camel Riders use various different technologies wired together in a variety of patterns with different _expression_ languages together with different forms of Bean Integration and Dependency Injection so its very easy for things to go wrong! . Testing is the crucial weapon to ensure that things work as you would expect. Camel is a Java library so you can easily wire up tests in whatever unit testing framework you use (JUnit 3.x, 4.x or TestNG). However the Camel project has tried to make the testing of Camel as easy and powerful as possible so we have introduced the following features. Testing mechanisms The following mechanisms are supported Name Description Camel Test is a library letting you easily create Camel test cases using a single Java class for all your configuration and routing without using Spring or Guice for Dependency Injection which does not require an in depth knowledge of Spring+SpringTest or Guice Spring Testing uses Spring Test together with either XML or Java Config to dependency inject your test classes Guice uses Guice to dependency inject your test classes In all approaches the test classes look pretty much the same in that they all reuse the Camel binding and injection annotations. Here is the Camel Test example Error formatting macro: snippet: java.lang.IllegalArgumentException: Invalid url: must begin with a configured prefix. Testing endpoints Camel provides a number of endpoints which can make testing easier. Name Description DataSet For load & soak testing this endpoint provides a way to create huge numbers of messages for sending to Components and asserting that they are consumed correctly Mock For testing routes and mediation rules using mocks and allowing assertions to be added to an endpoint Test Creates a Mock endpoint which expects to receive all the message bodies that could be polled from the given underlying endpoint The main endpoint is the Mock endpoint which allows expectations to be added to different endpoints; you can then run your tests and assert that your expectations are met at the end. Stubbing out physical transport technologies If you wish to test out a route but want to avoid actually using a real physical transport (for example to unit test a transformation route rather than performing a full integration test) then the following endpoints can be useful. Name Description Direct Direct invocation of the consumer from the producer so that single threaded (non-SEDA) in VM invocation is performed which can be useful to mock out physical transports SEDA Delivers messages asynchonously to consumers via a java.util.concurrent.BlockingQueue which is good for testing asynchronous transports

Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request

Unsubscribe or edit your notifications preferences