Unit testing the obvious - unit-testing

Question

While trying to write test cases for a class whose functionality deals more with boiler plate code than business logic. I started wondering if unit testing is really worth for this class. But then again, when using TDD, we are advised to write test for any piece of logic we add.
As an example the below class, just uses DI to inject dependencies and get config parameters to set up the running of the application. Other than unit testing if dependencies are correctly injected, or if destroy is called when running finishes(which would be unit testing the java CDI framework than my own code), what else I can unit test?
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.ejb.Singleton;
import javax.ejb.Startup;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.inject.Inject;
#Singleton
#Startup
#TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public class PipsAlprConnectionRunner {
#Inject
private PipsAlprConfiguration config;
#Inject
private PipsAlprConnector connector;
#Inject
private Scheduler scheduler;
#Inject
#PipsAlprAdapterService
private ServiceStatus status;
private Timer connectorTimer = null;
#PostConstruct
public void initialized() {
status.started();
connectorTimer = scheduler.schedule(connector, 0,
1000 * config.getPollPeriodSeconds());
status.operational();
}
#PreDestroy
public void destroy() {
connectorTimer.cancel();
connector.shutdown();
status.stopped();
}
}
I was unable to think of any testing scenarios to utilize TDD, on the above class, so just came up with the code, and now i am wondering what exactly can i unit test here.

Answer 1

Well, a case can be made that the class does something. It changes a status, it starts a timer. You can inject mocks of these objects into the class via Mockito and then make sure, that initialized() and destroy() both do what you expect them to do to these mocks.
#RunWith(MockitoJUnitRunner.class)
public class PipsAlprConnectionRunner {
#Mock
private PipsAlprConfiguration config;
#Mock
private PipsAlprConnector connector;
#Mock
private Scheduler scheduler;
#Mock
private ServiceStatus status;
#InjectMocks
private PipsAlprConnectionRunner pipsAlprConnectionRunner ;
#Test
public void initialized_should_set_status_started() {
pipsAlprConnectionRunner.initialized();
Mockito.verify(status).started();
}
// etc.
}
It's pretty much a question of personal taste if you want to create one method per "point of failure" or one method per method/test.
Personally, I would say that the goal is 100% coverage, so even pretty simple classes that mainly delegate should be covered. What happens if someone changes anything? The test ensures that such changes will not break existing functionality.