I work in a project where testing is a first class citizen. We do unit tests, security tests, integration tests, end-to-ends api tests (SBE), and end-to-end functional (interface based) tests also by using SBE.
All right, everything's fine, until I need to throw in some asserts at the end of my integration/sbe test where I should check if the whole process performed well. Ok, only that this part of the process is accomplished by quartz jobs that run asynchronously in their specific setup, beyond our control.
Note: The assumption for this post is that your Quartz scheduler can be run within the same application with your tested classes. For distributed quartz jobs there is another story.
Some could say, ok, by you have the possibility to get a job by it's name and call
triggerJob(JobKey) on a quartz scheduler instance, that should trigger the job immediately. But, be careful is about triggering a job, and not running the job. That means that:
- the command is asynchronous and return immediately;
- the job could actually start later, depending on the schedule's config and
- you don't actually know when the job shall finish so that you can test your assumptions about the outcome of it.
Two quick solutions:
- after test's execution finished, before asserting on data, sleep the test thread for a while to give quartz time to do it's work. But sleep for how long? Some manual tries could give us some empirical idea of how long should we wait before the jos is usually executed, but we are never going to be 100% sure it actually was. And then, this approach could bring the execution of our test suite to last forever, imagine running hundreds of tests of this type that each are sleeping for few seconds... It doesn't sound very appealing.
- add a JobListener listener to the scheduler, then trigger the job and then put your main thread in wait until the listener is triggered on execution finished, and notifies your main thread so it can resume it's testing task. But, again, there might be many jobs already triggered and running until ours get's it's change to run. And after all, would you really want to get into unexpected threading issues? I think not.
So, after trying the aforementioned approaches and not really being happy with them I thought, why not directly run the jobs I am directly interested in?
Well this is not that trivial, because I'd like to run the jobs as they are, without having to know what other stuff is injected in each of my classes extending
QuartzJob in order to make it work. So, after some research and study of how quartz works in collaboration with spring, that is what came out:
import org.quartz.Job;
import org.quartz.JobExecutionContext;
import org.quartz.Scheduler;
import org.springframework.beans.BeanWrapper;
import org.springframework.beans.BeansException;
import org.springframework.beans.MutablePropertyValues;
import org.springframework.beans.PropertyAccessorFactory;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
import java.lang.reflect.Method;
import java.util.Map;
public class ManualJobExecutor implements ApplicationContextAware {
private ApplicationContext applicationContext;
public void executeJob(final Class<Job> jobClass) {
try {
//create job instance
final Job quartzJob = jobClass.newInstance();
// For the created job instance, search all services that are injected by quartz.
// Those service instances are kept inside each scheduler context as a map
final BeanWrapper beanWrapper = PropertyAccessorFactory.forBeanPropertyAccess(quartzJob);
final MutablePropertyValues propertyValues = new MutablePropertyValues();
//get all schedulers defined across all spring configurations for this application
final Map<String, Scheduler> schedulers = applicationContext.getBeansOfType(Scheduler.class);
for (final Scheduler scheduler : schedulers.values()) {
// Populate the possible properties with service instances found
propertyValues.addPropertyValues(scheduler.getContext());
}
//set the properties of the job (injected dependencies) with the matching services
//the other services in the list that have no matching properties shall be ignored
beanWrapper.setPropertyValues(propertyValues, true);
//get method executeInternal(JobExecutionContext) from job class extending QuartzJobBean
final Method executeJobMethod = quartzJob.getClass().getDeclaredMethod("executeInternal", (JobExecutionContext.class));
executeJobMethod.setAccessible(true);
//call the processItems method on the Job class instance
executeJobMethod.invoke(quartzJob);
} catch (final Exception e) {
throw new RuntimeException(String.format("Exception while retrieving and executing job for name=%s", jobClass.getName()), e);
}
}
@Override
public void setApplicationContext(final ApplicationContext applicationContext) throws BeansException {
this.applicationContext = applicationContext;
}
}
That's it!
Of course there are also other aspects, i.e checking if other job of the same class is already executing so that it won't overlap with your execution. Usually in Quarz,
@DisableConcurrentExecution takes care of this but here you need to check it yourself.
You could also make your method accept a job by its name instead of class so you can get the names from your database instead of looking into project classes.
I hope this is going to ease your testing.
Please share your thoughts.
Have a nice day,
Dikran
