2008/12/3 Martin Gilday <[EMAIL PROTECTED]>:
> Thanks James.  One thing I meant to ask about Spring based testing was
> if you alter your route config for testing or not.  We have a Java DSL
> route file which includes quartz, jms and bean components.  If we wanted
> to unit/integration test this routebuilder config how are you making
> assertions on it?

One simple way is to parameterize your RouteBuilder so that in
testing, you can stub out endpoints with mock/direct endpoints.

e.g.

public class MyRouteBuilder extends RouteBuilder {
  String a = "quartz:whatnot";
  String b = "jms:someQueue";

  public void configure() {
    from(a).
      filter().xpath("/whatever").
      to(b);
  }

  // setters so you can overload in tests...
  public void setA(String a) {...}
  public void setB(String b) {...}
}

> At the moment we are subclassing the route definition
> for tests and overriding methods such as getFinalDestinationEndpointUri
> and changing it from a bean ref to a mock one.  We also reduce things
> like retry delay etc.  This seems slightly messy.

Maybe dependency injection is a bit cleaner? e.g. using constructor
arguments or setters on the route builder. Another strategy is to just
use named references in your routes; then let your IoC container or
JNDI provider map logical endpoint names to physical endpoints. If you
are using Spring or Guice then you can properties files to overload
URIs you use between development/integration testing/production.


> The wiki page seems
> to only ever refer to route configs which already have the names of mock
> endpoints in etc.  But I wouldn't think this would naturally be what you
> have. Do you only ever write route defs for your tests and not test your
> real 'live' route config?

I guess it depends on what kind of testing you want to do. For Unit
Testing transformations, you often can have separate routes. For
Integration Testing you probably want to use the real production
configuration (with one or two endpoint URIs changed here or there).

-- 
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

Reply via email to