How can I make a JUnit test wait?

JavaJunitThread Safety

Java Problem Overview


I have a JUnit test that I want to wait for a period of time synchronously. My JUnit test looks like this:

@Test
public void testExipres(){
    SomeCacheObject sco = new SomeCacheObject();
    sco.putWithExipration("foo", 1000);
    // WAIT FOR 2 SECONDS
    assertNull(sco.getIfNotExipred("foo"));
}

I tried Thread.currentThread().wait(), but it throws an IllegalMonitorStateException (as expected).

Is there some trick to it or do I need a different monitor?

Java Solutions


Solution 1 - Java

How about Thread.sleep(2000); ? :)

Solution 2 - Java

Thread.sleep() could work in most cases, but usually if you're waiting, you are actually waiting for a particular condition or state to occur. Thread.sleep() does not guarantee that whatever you're waiting for has actually happened.

If you are waiting on a rest request for example maybe it usually return in 5 seconds, but if you set your sleep for 5 seconds the day your request comes back in 10 seconds your test is going to fail.

To remedy this JayWay has a great utility called Awatility which is perfect for ensuring that a specific condition occurs before you move on.

It has a nice fluent api as well

await().until(() -> 
{
    return yourConditionIsMet();
});  

https://github.com/jayway/awaitility

Solution 3 - Java

You can use java.util.concurrent.TimeUnit library which internally uses Thread.sleep. The syntax should look like this :

@Test
public void testExipres(){
    SomeCacheObject sco = new SomeCacheObject();
    sco.putWithExipration("foo", 1000);
    
    TimeUnit.MINUTES.sleep(2);
   
    assertNull(sco.getIfNotExipred("foo"));
}

This library provides more clear interpretation for time unit. You can use 'HOURS'/'MINUTES'/'SECONDS'.

Solution 4 - Java

In case your static code analyzer (like SonarQube) complaints, but you can not think of another way, rather than sleep, you may try with a hack like: Awaitility.await().pollDelay(Durations.ONE_SECOND).until(() -> true); It's conceptually incorrect, but it is the same as Thread.sleep(1000).

The best way, of course, is to pass a Callable, with your appropriate condition, rather than true, which I have.

https://github.com/awaitility/awaitility

Solution 5 - Java

If it is an absolute must to generate delay in a test CountDownLatch is a simple solution. In your test class declare:

private final CountDownLatch waiter = new CountDownLatch(1);

and in the test where needed:

waiter.await(1000 * 1000, TimeUnit.NANOSECONDS); // 1ms

Maybe unnecessary to say but keeping in mind that you should keep wait times small and not cumulate waits to too many places.

Solution 6 - Java

You could also use the CountDownLatch object like explained here.

Solution 7 - Java

There is a general problem: it's hard to mock time. Also, it's really bad practice to place long running/waiting code in a unit test.

So, for making a scheduling API testable, I used an interface with a real and a mock implementation like this:

public interface Clock {
    
    public long getCurrentMillis();
    
    public void sleep(long millis) throws InterruptedException;
    
}

public static class SystemClock implements Clock {

    @Override
    public long getCurrentMillis() {
        return System.currentTimeMillis();
    }

    @Override
    public void sleep(long millis) throws InterruptedException {
        Thread.sleep(millis);
    }
    
}

public static class MockClock implements Clock {

    private final AtomicLong currentTime = new AtomicLong(0);
    

    public MockClock() {
        this(System.currentTimeMillis());
    }
    
    public MockClock(long currentTime) {
        this.currentTime.set(currentTime);
    }
    

    @Override
    public long getCurrentMillis() {
        return currentTime.addAndGet(5);
    }

    @Override
    public void sleep(long millis) {
        currentTime.addAndGet(millis);
    }
    
}

With this, you could imitate time in your test:

@Test
public void testExpiration() {
    MockClock clock = new MockClock();
    SomeCacheObject sco = new SomeCacheObject();
    sco.putWithExpiration("foo", 1000);
    clock.sleep(2000) // wait for 2 seconds
    assertNull(sco.getIfNotExpired("foo"));
}

An advanced multi-threading mock for Clock is much more complex, of course, but you can make it with ThreadLocal references and a good time synchronization strategy, for example.

Solution 8 - Java

Mockito (which is already provided via transitive dependencies for Spring Boot projects) has a couple of ways to wait for asynchronous events, respectively conditions to happen.

A simple pattern which currently works very well for us is:

// ARRANGE – instantiate Mocks, setup test conditions

// ACT – the action to test, followed by:
Mockito.verify(myMockOrSpy, timeout(5000).atLeastOnce()).delayedStuff();
// further execution paused until `delayedStuff()` is called – or fails after timeout

// ASSERT – assertThat(...)

Two slightly more complex yet more sophisticated are described in this article by @fernando-cejas


My urgent advice regarding the current top answers given here: you want your tests to

  1. finish as fast as possible
  2. have consistent results, independent of the test environment (non-"flaky")

... so just don't be silly by using Thread.sleep() in your test code.

Instead, have your production code use dependency injection (or, a little "dirtier", expose some mockable/spyable methods) then use Mockito, Awaitly, ConcurrentUnit or others to ensure asynchronous preconditions are met before assertions happen.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionKylarView Question on Stackoverflow
Solution 1 - JavaMuelView Answer on Stackoverflow
Solution 2 - JavaBen GlasserView Answer on Stackoverflow
Solution 3 - JavaAkshay PagarView Answer on Stackoverflow
Solution 4 - JavaRostislav VView Answer on Stackoverflow
Solution 5 - JavapirhoView Answer on Stackoverflow
Solution 6 - JavaPierre VoisinView Answer on Stackoverflow
Solution 7 - JavaDávid HorváthView Answer on Stackoverflow
Solution 8 - JavaPhilzenView Answer on Stackoverflow