Spring Batch Java configuration unit test

Batch job/steps/beans can be configured using Java class in Spring Batch. Just curious do we need unit test this configuration Java class. I saw lots of talking about integration tests, but little on unit tests for Spring Batch. A sample Java class like below (from a Spring Batch book):

@Configuration
public class Demo9 {

    private JobBuilderFactory jobBuilderFactory;
    private StepBuilderFactory stepBuilderFactory;
    private EmployeeProcessor employeeProcessor;
    private DataSource dataSource;

    @Autowired
    public Demo9(JobBuilderFactory jobBuilderFactory, StepBuilderFactory stepBuilderFactory, EmployeeProcessor employeeProcessor, DataSource dataSource) {
        this.jobBuilderFactory = jobBuilderFactory;
        this.stepBuilderFactory = stepBuilderFactory;
        this.employeeProcessor = employeeProcessor;
        this.dataSource = dataSource;
    }

    @Qualifier(value = "demo9")
    @Bean
    public Job demo9Job() throws Exception {
        return this.jobBuilderFactory.get("demo9")
                .start(step1Demo9())
                .build();
    }

    @Bean
    public Step step1Demo9() throws Exception {
        return this.stepBuilderFactory.get("step1")
                .<EmployeeDTO, Employee>chunk(2)
                .reader(employeeReader())
                .processor(employeeProcessor)
                .writer(employeeDBWriterDefault())
                .build();
    }

    @Bean
    @StepScope
    Resource inputFileResource(@Value("#{jobParameters[fileName]}") final String fileName) throws Exception {
        return new ClassPathResource(fileName);
    }

    @Bean
    @StepScope
    public FlatFileItemReader<EmployeeDTO> employeeReader() throws Exception {
        FlatFileItemReader<EmployeeDTO> reader = new FlatFileItemReader<>();
        reader.setResource(inputFileResource(null));
        reader.setLinesToSkip(1);
        reader.setSkippedLinesCallback(new SkipRecordCallback());
        reader.setLineMapper(new DefaultLineMapper<EmployeeDTO>() {{
            setLineTokenizer(new FixedLengthTokenizer() {{
                setNames("employeeId", "firstName", "lastName", "email", "age");
                setColumns(new Range[]{new Range(1, 5), new Range(6, 10), new Range(11, 15), new Range(16, 30), new Range(31, 33)});
                setStrict(false);
            }});
            setFieldSetMapper(new EmployeeFileRowMapper());
        }});
        return reader;
    }

    @Bean
    public JdbcBatchItemWriter<Employee> employeeDBWriterDefault() {
        JdbcBatchItemWriter<Employee> itemWriter = new JdbcBatchItemWriter<Employee>();
        itemWriter.setDataSource(dataSource);
        itemWriter.setSql("insert into employee (employee_id, first_name, last_name, email, age) values (:employeeId, :firstName, :lastName, :email, :age)");
        itemWriter.setItemSqlParameterSourceProvider(new BeanPropertyItemSqlParameterSourceProvider<Employee>());
        return itemWriter;
    }    
}

Want to have an idea we are possible to unit test this?

I personally won't do that. This code is to configure Spring Batch (not the code of the business logic of the batch job itself). One could argue that this is code, so it should be tested. That is true, but pragmatically speaking, I would focus on testing the business logic of my batch job rather than the code of configuring Spring (Batch), which could have been an XML configuration file.

That code will be implicitly tested when you test your batch job. For example, the Spring application context won't start, or the job will fail to start because it is incorrectly configured, etc. You will notice these misconfigurations in tests, and I see no need to write a unit test to make sure that the employeeReader() method returns a bean of type FlatFileItemReader for example.