Testing

Really easy

Testing an "Easy Batch" job was, indeed, really easy. There is no magic inside the engine, no annotations, and no complications. This simplification makes testing easy too. But enough words. Let's start testing.

Integration tests

For integration tests, we decided to use really similar cases than the "JDBC example". We need to test processing and database interactions so we think that was the way. Let's review UVALoanFeeUpdateEasyBatchJobIntegrationTests.java.

As you can see we are reusing the previous JDBC Extension because we want those in memory database features.

public class UVALoanFeeUpdateEasyBatchJobIntegrationTests {

...

@InMemoryDatasource
public DataSource datasource;
	
...
	
private static final String SCHEMA_FILE_NAME = "test-schema-batch.sql";
private static final String MODEL_FILE_NAME = "test-model-batch.xml";
	
@RegisterExtension
public static final JdbcIntegrationExtension extension = JdbcIntegrationExtension.builder().build(SCHEMA_FILE_NAME,MODEL_FILE_NAME);

...

Great we are already benefiting of Jumahuaca framework and now the test is really simple:

@IntegrationTest
public void testLaunchJobShouldUpdateOk() {
		JobReport report = launcher.runJob(LOAN_ID);
		assertThat(report.getStatus()).isEqualTo(JobStatus.COMPLETED);
		List<UVALoanFee> fees = feeDao.findByLoanId(LOAN_ID);
		List<UVALoanFee> toCompare = buildToBeWrittenFakeResult();
		assertThat(fees).isEqualTo(toCompare);
		
	}

As you can see we are using the launcher without mocking and all the data configuration occurs in the xml and sql file but that's a problem of Jumahuaca extension, you only have to worry to write good assertions.

And that's it for the integration tests, now we want to talk about the unit ones.

The classical Jumahuaca formula: extension + interface

We need to build the unit tests and we have a lot to mock so in Jumahuaca we have a common pattern for these situations. We like to give you an extension that forces you to do the mocking in the test case class. It's a simple solution and we will use it. Let's see it in action in UVALoanFeeUpdateEasyBatchJobTests.java

public class UVALoanFeeUpdateEasyBatchJobTests implements TestDoubleBatchHelper{

...
	@RegisterExtension
	public final EasyBatchExtension<UVALoanFeeRecord, UVALoanFeeRecord> extension = new EasyBatchExtension<UVALoanFeeRecord, UVALoanFeeRecord>();

...

And now the extension itself.

@SuppressWarnings("rawtypes")
public class EasyBatchExtension<P extends Record, R extends Record> implements Extension {

	private static final String JOB_NAME = "TESTING EXTENSION JOB";

	public JobReport launchTestingBatch(RecordReader reader, RecordFilter<P> filter, RecordProcessor<P, R> processor,
			RecordWriter writer, TestDoubleBatchHelper helper) {
		helper.mockInjectionsReadOk();
		helper.mockInjectionsProcessOk();
		helper.mockInjectionsWriteOk();
		
		Job job = new JobBuilder().named(JOB_NAME).reader(reader).filter(filter).processor(processor).writer(writer)
				.build();

		JobExecutor jobExecutor = new JobExecutor();
		JobReport report = jobExecutor.execute(job);
		jobExecutor.shutdown();
		return report;
	}

}

As you can see we force you to implement the mocking and then we emulate the launcher behavior in a simpler way.

Then the testing is really straightforward:

@Test
public void testJobShouldUpdateOk()
			throws Exception {

		JobReport report = extension.launchTestingBatch(reader, filter, processor, writer, this);
		assertThat(report.getStatus()).isEqualTo(JobStatus.COMPLETED);
		List<UVALoanFee> toCompare = buildToBeWrittenFakeResult();
		verify(feeRepository).update(argThat((arg) -> arg.equals(toCompare.get(0))));
		verify(feeRepository).update(argThat((arg) -> arg.equals(toCompare.get(1))));
	}