Manually triggering and waiting for Quartz.Net job

Question

We've just upgraded from Quartz.Net 3.2.4 to 3.3.3 and one of our integration tests unfortunately has broken. We're trying to test a Quartz job and the way the test did it was getting an instance of the job via the ServiceProvider and calling Execute().

var deleteExpiredPendingFileCleanupTask = scope.ServiceProvider.GetService<DeleteExpiredPendingFileCleanupTask>();
var jobExecutionContext = new Mock<IJobExecutionContext>();

await deleteExpiredPendingFileCleanupTask.Execute(jobExecutionContext.Object);

Unfortunately Quartz.Net doesn't seem to create an instance of the service anymore, GetService() comes back with null. I've been hunting around for one of two solutions I've thought of:

• Is there a way to create an instance of the job (with DI and such) to execute like before
• Is there a way to wait for a manually triggered job and block until it to completes

I'm not sure if there might be a third solution I haven't thought of, but for those two I'm hoping someone might have an answer I've missed. I see this unanswered question asking about the second of those ideas.

The temporary solution I've found is manually creating the service in our integration testing startup, but this is less than ideal because it doesn't match the actual production configuration.

services.AddScoped<DeleteExpiredPendingFileCleanupTask, DeleteExpiredPendingFileCleanupTask>();

Thanks.

Answer 1

Quartz changed the logic in a way that it no longer automatically registers the jobs into container, but does try to resolve them if they are manually registered, see MicrosoftDependencyInjectionJobFactory. So your approach of registering the job manually is valid and you could do that for your production configuration too - as long as they are scoped like your configuration shows.

There's no built-in way to wait for manually triggered job, this is a bit hard if you think about a clustered setup where job could be run on any node. If you want this only in your tests you could register a ITriggerListener or a IJobListener and track a mutex/semaphore which you could then set/monitor and create a communication channel between job and the test.