Improve @SpringBatchTest to autowire the job under test in JobLauncherTestUtils if it is unique

[hpoettker]

To resolve #1237, the feature to always autowire a job into JobLauncherTestUtils was removed as the autowiring leads to issues if there is no unique candidate in the test context.

This PR adds the flag autowireJob to the annotation @SpringBatchTest. If set to true, the developer opts in to the old behavior.

Using narrowly defined test contexts when writing unit tests for jobs is a good practice in my opinion. Similar to using test slices for a Spring Boot application, it can have a strong influence on the run-time of build pipelines and thus tighten feedback cycles during development.

The proposed change is intended to be an incentive for test contexts that contain only the job to be tested. Additionally, it simplifies migration to Spring Batch 5 a bit for developers that relied on the old behavior.

[fmbenhassine]

To resolve #1237, the feature to always autowire a job into JobLauncherTestUtils was removed as the autowiring leads to issues if there is no unique candidate in the test context.

We had an internal discussion about this, and one of the ideas that came out to address the case where multiple jobs are defined in the test context was to add an attribute with the name of the job to autowire in JobLauncherTestUtils. We decided to not implement this feature as such an information is statically defined in an annotation (and would also "encourage" a bad practice that we want avoid in the first place).

Using narrowly defined test contexts when writing unit tests for jobs is a good practice in my opinion.

I couldn't agree more! See my comment here: #3699 (comment)

The proposed change is intended to be an incentive for test contexts that contain only the job to be tested. Additionally, it simplifies migration to Spring Batch 5 a bit for developers that relied on the old behavior.

For the case where a single job is defined, I think there is a room for improvement with a sensible default. What you suggest is a good idea IMO. However, do we really need a flag for that? What about autowiring the job in JobLauncherTestUtils if there is only one? This removes the need for a flag and is nearly the same behaviour as in v4. wdyt?

[hpoettker]

Thanks for the feedback! I've implemented the proposal to only inject a job into JobLauncherTestUtils if it's unique.

For me personally this solution would work very well. I'm wondering however if it's not too "magical" for developers who are not aware of the underlying mechanism. To them it might seem that the injection process is flaky as "sometimes" a job is injected and "sometimes" not.

The original commit with the flag has the advantage that it's clearer how it works: If the flag is not set, then no job will be injected. Otherwise, a job will be injected or the test fails while trying to do so.

[fmbenhassine]

Thank you for your feedback and for the quick update!

For me personally this solution would work very well.

I believe this is because you are applying the best practice of isolating tests for each job. And this would work very well too for anyone who is applying this best practice. My thinking with the suggested default is as follows: It is unfair to make users who apply the best practice (of isolating tests) to pay the price of autowiring the single job in test utilities.

I'm wondering however if it's not too "magical" for developers who are not aware of the underlying mechanism. To them it might seem that the injection process is flaky as "sometimes" a job is injected and "sometimes" not.

There is no magic. Magical is only magical if it is not documented. I will refer anyone who would complain about this being magical to this tweet by Josh 😄 . That said, I see no note about this new default in the Javadoc of SpringBatchTest in this PR. I will take care of that on merge.

Thanks again for all your contributions! REALLY appreciated 👍

[fmbenhassine]

Rebased and merged as 3bb7ce5. Revised in 1527593. Thank you for your contribution!