Testing Multithreaded Scheduled Tasks

Question

For the first time I was doing some multi threading work and as to often I went the inverse TDD way: implemented the task and afterwards I start thinking how to test the whole thing. Well done!

Well, I found Alex Collins explanation helpful and it was a real eye opener.

But my threading system is scheduled and it is periodically restarting a for- and backwards initialisation. e.g.

@Before
public void assertCallModelEmpty() {
    assertThat(CallModel.count()).isEqualTo(0);     
}

@After
public void tearDownBackwardsThread() {
    CallServicesFactory.getCallServices().stopCdrBackwardsInit();
}

@Test(timeout = 6000)
public void runWithObserver() throws InterruptedException, UnfinishedCallException, ParseException {
    // given
    CallServices callServices = CallServicesFactory.getCallServices();
    callServices.initFrom(startDate);
    assertThat(CallModel.count()).isEqualTo(1);

    // when 1
    Date start = new DateTime().plusSeconds(1).toDate();
    int intervalInSec = 1;
    int initDaysPerNight = 2;
    callServices.runCdrBackwardsInit(start, initDaysPerNight, intervalInSec);
    Thread.sleep(1500);

    // then 1
    assertThat(CallModel.count()).isEqualTo(2);

    // when 2
    Thread.sleep(1500);

    // then 2
    assertThat(CallModel.count()).isEqualTo(3);

    // when 3
    Thread.sleep(1500);

    // then 3
    assertThat(CallModel.count()).isEqualTo(4);
}

I tried with leting the main thread sleep so the other thread can do its work but the problem, as mentioned in many other places, is that the behavoir of the test is different from machine to machine and the test gets to long for quick developer tests.

I only see two solutions:

1. changing the design of the implementation so that the whole thing is testable without the threads but then I'll lose a certain logic of the whole system and it's quite some work to do
2. isolating these tests so that it's not a developer test anymore but rather a integration test.

Any other suggestions?

Conclution: always do TDD!

Answer 1

The best long term solution is 1, but you don't need to do this in one single shot.

Solution 1 reduce the development cycle time, give better feedback on failures and help you to design few coupled units.

But in real world, you don't have much time and can't get uncovered, so you should do solution 2 and incrementally extract non threaded code from the threaded using tests to make sure the behavior is the same.

When you get statisfied with unit test coverage, you may decide if you mantain the integration test running on your CI or not.