# Best practices for testing sleep logic

**URL:** <https://community.temporal.io/t/best-practices-for-testing-sleep-logic/16217>\
**Category:** Community Support\
**Tags:** testing, typescript-sdk\
**Created:** [January 23, 2025, 5:54pm UTC](https://community.temporal.io/t/best-practices-for-testing-sleep-logic/16217 "2025-01-23T17:54:48Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![mdiamond](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/mdiamond/32/6684_2.png) [@mdiamond](https://community.temporal.io/u/mdiamond)\
**Post date:** [January 23, 2025, 5:54pm UTC](https://community.temporal.io/t/best-practices-for-testing-sleep-logic/16217/1 "2025-01-23T17:54:48Z")

</div>

I’m writing a medium test for a workflow and would like to test that the sleep logic behaves as expected. My first attempt was to do something like this:

```typescript
test('should sleep for 1 day after a failed attempt', async () => {
  const startTime = await temporal.env.currentTimeMs();
  let elapsedTime = 0;
  myMockActivity
    .mockReturnValueOnce(false)
    .mockImplementationOnce(async () => {
      elapsedTime = (await temporal.env.currentTimeMs()) - startTime;
      return true;
    });
  await run('123', temporal);
  // 1 day in milliseconds is 86400000
  expect(elapsedTime).toBe(86400000);
});

```

However, this obviously doesn’t work since the elapsed time will rarely ever be exactly 86400000 milliseconds. I _could_ change it so that it checks that the value is within ±500 ms, but that seems kind of hacky.

I asked the Temporal Docs AI and it gave me another suggestion: run the workflow without automatic time skipping, advance time by `23h59m59s`, verify that the next activity hasn’t been called, then advance it by 1 or 2 seconds and check that the activity has been called. However, this also seems a bit suboptimal.

Is there a better way to approach the problem of testing time logic? Obviously I trust that the Workflow will sleep for whatever interval I give it – I’m not trying to test the `Workflow.sleep()` function itself – but if a workflow has a more complex system of sleep logic it would be nice to verify that everything followed the expected schedule.