ehance testability of clients

cool library with some interesting ideas.

Ideally, I was trying to create a simple wrapper to hide jesque(and simulate jesque) from a testability perspective. Unfortunately, the design seems to be preventing that or I am missing a method I could use? Perhaps you might know?

I was trying to create a singleton like so

public class ResqueWrapper {

public void addQueueListener(ResqueListener l, Collection<String> queueNames) {
  //VERY VERY little code that I can only test in staging
}

public void remoteQueueListener(ResqueListener l) {
}

}

As I got into implementing this, I found out jesque is doing some reflection stuff that I would like to avoid especialy since it is on my business logic and I prefer to have all business logic stateless and created via guice. I really just want jesque to call

resqueListener.processItemsInQueue(String fromQueue, Items items)
resqueListener.failed(fromQueue, Throwable t)

where Items has an ack or nack. Then I can fully simulate my system. Unfortunately, jesque is making it really hard to wrap my system in a 'large' system type test where I swap out guice remote endpoints(so it's all single threaded and doesn't talk remotely at all during the test). This enables us to test talking to S3 failures after getting a resque item and make sure the system does what it is supposed to on an S3 failure or an mysql failure, etc. etc.

Is there any way to do this?

For one thing, the reflection to create a job class is what is hurting me. Reflection to create a data object to pass into a generic resque listener would have been ok like ResqueListener

Ideally, the api should only be passing data rather than fiddling with my business logic such that my test can easily do the same. It just creates a situation in which the test can simulate 99% of the code rather than 70% of the code which is what we have right now.

It's hard to explain this concept, but basically our tests on other projects do this

1. feed in data through to the listener(test has a reference to the listener as it mocks the ResqueWrapper to be able to grab the listeners that were added)
2. from there it is 100% production code until the remote endpoint
3. at the remote endpoint, our test throws an exception
4. then we verify a call to mysql results in recording that exception as well(which again is a mocked endpoint).

thanks,
Dean