Injecting specific implementations at unit test time

[Ron McLeod]

During unit testing, depending on the test case, I need to use different implementations of a storage class, including contrived instances which have a particular behaviour needed to satisfy the test case.

What I am doing below does work, but I feel that there may be a better what to do this, maybe by using some features of CDI or using something like Mockito.

Any suggestions?

@QuarkusTest  // for CDI
public class Es9plusTransactionManagerTest {
	@Inject Es9plusTransactionManager manager;
	@Inject InMemoryEs9plusTransactionStore inMemoryStore;
	int attemptCount;

	@BeforeEach
	void init() {
		attemptCount = 0;
		// The manager is ApplicationScoped
		// Restore the store before each test in case it was modified by a particular case
		manager.setTransactionStore(inMemoryStore);
	}

	@Test
	void idCollision() {
		// use mock store which always indicates that the ID already exists
		manager.setTransactionStore(new Es9plusTransactionStore() {
			@Override
			public void update(Es9plusTransaction transaction) throws Es9plusTransactionException {}
			@Override
			public void remove(byte[] id) throws Es9plusTransactionException {}
			@Override
			public Es9plusTransaction get(byte[] id) throws Es9plusTransactionException {return null;}
			@Override
			public boolean exists(byte[] id) {return false;}
			@Override
			// always throw exception so that it appears that the ID exists
			public void add(Es9plusTransaction transaction) throws Es9plusTransactionException {
				attemptCount++;
				throw new Es9plusTransactionException(Reason.TRANSACTION_EXISTS);
			}
		});
		
		try {
			manager.create();
			fail("Expected exception stating that transaction could not be created");
		} catch (Es9plusTransactionException e) {
			assertEquals(Reason.CANNOT_CREATE_TRANSACTION, e.getReason());
			assertEquals(Es9plusTransactionManager.MAX_NUM_ATTEMPTS_CREATE_NEW_TRANS, attemptCount);
		}
	}
}

@ApplicationScoped
public class Es9plusTransactionManager implements Es9plusTransactionUpdateListener {
	static final int MAX_NUM_ATTEMPTS_CREATE_NEW_TRANS = 5;
	private Es9plusTransactionStore store;

	@Inject
	void setTransactionStore(Es9plusTransactionStore store) {
		this.store = store;
	}

	public Es9plusTransaction create() throws Es9plusTransactionException {
		int attemptCount = MAX_NUM_ATTEMPTS_CREATE_NEW_TRANS;
		Es9plusTransaction trans = null;
		do {
			byte[] id = createNewRandomId();
			try {
				trans = create(id);
			} catch (Es9plusTransactionException e) {
				if (e.getReason() == Reason.TRANSACTION_EXISTS) {
					// id collision, try again
					attemptCount--;
					continue;
				} else {
					// re-throw unexpected exception
					throw e;
				}
			}
			// no exception means things went OK, no need to try again
			attemptCount = 0;
		} while (attemptCount > 0);

		// verify that a new transaction was actually created
		if (trans == null) {
			throw new Es9plusTransactionException(Reason.CANNOT_CREATE_TRANSACTION,
					"Failed to create transaction with unique transaction ID");
		}
		return trans;
	}

	public Es9plusTransaction create(byte[] id) throws Es9plusTransactionException {
		Es9plusTransaction trans = new Es9plusTransaction(id, this);
		store.add(trans);
		return trans;
	}

	...
}

public interface Es9plusTransactionStore {
	public Es9plusTransaction get(byte[] id) throws Es9plusTransactionException;
	public void add(Es9plusTransaction transaction) throws Es9plusTransactionException;
	public void update(Es9plusTransaction transaction) throws Es9plusTransactionException;
	public boolean exists(byte[] id);
	public void remove(byte[] id) throws Es9plusTransactionException;
}

@Dependent
@Alternative
public class InMemoryEs9plusTransactionStore implements Es9plusTransactionStore {
	...
}

[Tim Holloway]

I'm not sure how unit test works with CDI, since I started out using Spring and Spring and CDI were not playing well together last time I tried - which admittedly was a long time ago.

For Spring, I could just run a suite using multiple wirings. Spring doesn't depend on a container, however, and as far as I know, CDI does, so that part isn't clear to me.

I should point out that strictly speaking "Unit" tests are not supposed to call other modules anyway. That's an integration test. However, JUnit works pretty well at the integration test level also.

Also, strictly speaking, if you have plug-replaceable components and the components are all unit-test valid, then a test using one should potentially be a test for all.

I'd also argue that when you are testing anything that needs to call out for services, whether it's mail, web services, or something more exotic, then it's best that you call a mock service and not a live service. Obviously especially for email tests, where you don't want to spam the world, but also generally, since you're less likely to receive unexpected responses from a standard mock than a live component.

[Ron McLeod]

Tim Holloway wrote:I'm not sure how unit test works with CDI, since I started out using Spring and Spring and CDI were not playing well together last time I tried - which admittedly was a long time ago.

For Spring, I could just run a suite using multiple wirings. Spring doesn't depend on a container, however, and as far as I know, CDI does, so that part isn't clear to me.

I've never needed to use Spring so I'm not sure if some of the methodologies uses with Spring would also be applicable for Jakarta and CDI.

I should point out that strictly speaking "Unit" tests are not supposed to call other modules anyway. That's an integration test. However, JUnit works pretty well at the integration test level also.

Also, strictly speaking, if you have plug-replaceable components and the components are all unit-test valid, then a test using one should potentially be a test for all.

This is a unit test, but the unit under test has injected dependencies which effect its behaviour.  I have separate unit tests for those dependencies to verify their behaviour.

I'd also argue that when you are testing anything that needs to call out for services, whether it's mail, web services, or something more exotic, then it's best that you call a mock service and not a live service. Obviously especially for email tests, where you don't want to spam the world, but also generally, since you're less likely to receive unexpected responses from a standard mock than a live component.

No live services in my unit test.  For testing, I have a store implementation which simply uses a Map.  

@Dependent
@Alternative
public class InMemoryEs9plusTransactionStore implements Es9plusTransactionStore {
	private Map<BigInteger, Es9plusTransaction> transactions = new ConcurrentHashMap<>();

	@Override
	public Es9plusTransaction get(byte[] id) throws Es9plusTransactionException {
		Es9plusTransaction trans = transactions.get(new BigInteger(id));
		if (trans == null) {
			throw new Es9plusTransactionException(Reason.TRANSACTION_NOT_FOUND);
		}
		return trans;
	}

	@Override
	public void add(Es9plusTransaction transaction) throws Es9plusTransactionException {
		if (exists(transaction.getId())) {
			throw new Es9plusTransactionException(Reason.TRANSACTION_EXISTS);
		}
		transactions.put(new BigInteger(transaction.getId()), transaction);
	}

	@Override
	public void update(Es9plusTransaction transaction) throws Es9plusTransactionException {
		if (!exists(transaction.getId())) {
			throw new Es9plusTransactionException(Reason.TRANSACTION_NOT_FOUND);
		}
		transactions.put(new BigInteger(transaction.getId()), transaction);
	}

	@Override
	public boolean exists(byte[] id) {
		return transactions.containsKey(new BigInteger(id));
	}

	@Override
	public void remove(byte[] id) throws Es9plusTransactionException {
		if (!exists(id)) {
			throw new Es9plusTransactionException(Reason.TRANSACTION_NOT_FOUND);
		}
		transactions.remove(new BigInteger(id));
	}
}

In production it would use a database, document store, or a storage service.

[Stephan van Hulst]

This seems like a pretty simple test case to me. It boils down to two things:

You want to test that your manager service throws an exception.

You want to test that a mock service it depends on has been called a certain number of times.

You don't need CDI. Just the standard tools that JUnit and your mocking framework offer you:

@Rule
public ExpectedException expectedException = ExpectedException.none();

@Test
void testCreate_throwsException_afterMultipleFailedAttemptsToStoreTransaction() throws Exception {
  var mockedTransactionStore = mock(Es9plusTransactionStore.class);
  
  doThrow(new Es9plusTransactionException(TRANSACTION_EXISTS))
    .when(mockedTransactionStore).add(any());

  var testTransactionManager = new Es9plusTransactionManager();
  testTransactionManager.setTransactionStore(mockedTransactionStore);

  expectedException.expect(Es9plusTransactionException.class);
  expectedException.expectMessage(CANNOT_CREATE_TRANSACTION);

  try {
    testTransactionManager.create();
  }

  finally {
    verify(mockedTransactionStore, times(MAX_NUM_ATTEMPTS_CREATE_NEW_TRANS)).add(any());
  }
}

1. Mock dependencies.
2. Configure test object.
3. Configure expected exceptions.
4. Call test object.
5. Verify return value.
6. Verify calls on mocked dependencies.

[Tim Holloway]

Spring is a generic bean factory and  IoC injection framework and can be used anywhere, including in stand-alone apps. It predates CDI and provides an extensive set of services, including Spring Data, which takes care of a lot of the grunt work for transaction-based persistent storage operations. So when CDI first came out, naturally I wanted to get the best of both worlds, just as I could using the JSF/Spring bridge where JSF ManagedBeans could freely interconnect with Spring beans and Spring beans and their properties could be referenced on View Templates using Expression Language (EL). But that's just background, not of particular interest here.

@Inject'ed items are not magic. All the @Inject annotation does is mark the property as something for the framework to wire into. If a unit test wants to manually set the @Inject'ed property in lieu of a CDI container doing so, there is absolutely nothing wrong with that. And, after all, one of the primary benefits of systems like jUnit is that they can do testing without the tremendous overhead it takes to crank up a container.

Beyond those comments, I'll defer to Stephan who's more in touch with your particular situation.