Make it easy to run integration tests against complex job orchestrations

[nulltoken]

Is your feature request related to a problem? Please describe.
👋 Given some state and a complex job definition (multiple jobs with dependencies (each of them also having dependencies), exception handler, ...) ,I'd like a way to test that everything worked as expected.

From a very high level standpoint, I'd like to "await" a InstantJob execution from a xunit test, and then perform assertions.

Describe the solution you'd like
There are many different approaches but the simplest that came to mind was something like a final delegate based hook that would be triggered once all the chain of jobs (and potential notification/exception handlers) have been run.

This might be implemented by adding non breaking overloads to IInstantJobRegistry.

void RunInstantJob<TJob>(object? parameter = null, Delegate completionNotifier, CancellationToken token = default)
void RunInstantJob(Delegate jobDelegate, Delegate completionNotifier, CancellationToken token = default);

Given this hypothetical hook, one could leverage the black magic of CancellationTokens to let the test know when the job run is completed.

Describe alternatives you've considered
I've briefly considered IJobNotificationHandler but it doesn't fit the bill the following reasons:

• it targets a known typed job
• the complex job definition may have numerous "leaf" job (final stop of an job orchestration)

Additional context
My current use case is test oriented. I haven't deeply thought whether or not this might be handy in a real production oriented scenario.

[linkdotnet]

Yeah that is indeed some pain in the lower-part of the human body ;)

The "clean" solution would be #36 where we would allow a monitoring system to observe state changes of jobs and related parts (scheduler, executor, ...).

Given this hypothetical hook, one could leverage the black magic of CancellationTokens to let the test know when the job run is completed.

We already do similar things in the NCronJob test suite. We use channels to communicate between the test-task and the job-task to signal various state changes. It is by far ideal and is also solved by #36

[nulltoken]

The "clean" solution would be #36 where we would allow a monitoring system to observe state changes of jobs and related parts (scheduler, executor, ...).

Makes sense. Although, at first view, this seems like a huge thing to build for the sole purpose of being notified of the completion of an instantjob triggered orchestration.

Let me think about this for some time.

I'll come back with some pseudo code from the "how would I like to leverage this from my test suite" angle and we'll see how to make ends meet.

We already do similar things in the NCronJob test suite. We use channels to communicate between the test-task and the job-task to signal various state changes. It is by far ideal and is also solved by #36

Obviously, I don't want to alter my $DAYJOB NCronJob jobs production code with channels for the sake of testing 😉
And indeed, finding a way to make the tests in this repository easier to read/maintain would be a great benefit.