[Bug?]: `slow imports › usePageLoadingContext` possible flakey unit test

[virtuoushub]

possible flakey test:

test code: https://github.com/redwoodjs/redwood/blob/main/packages/router/src/__tests__/router.test.tsx#L502-L545

FAIL   code  src/__tests__/router.test.tsx (50.835 s)
  ● slow imports › usePageLoadingContext

    expect(element).not.toBeInTheDocument()

    expected document not to contain element, found <p>loading in page...</p> instead

      536 |       // This shouldn't show up, because the page shouldn't render before it's
      537 |       // fully loaded
    > 538 |       expect(screen.queryByText('loading in page...')).not.toBeInTheDocument()
          |                                                            ^
      539 |
      540 |       await waitFor(() => screen.getByText('done loading in page'))
      541 |       await waitFor(() => screen.getByText('done loading in layout'))

      at Object.toBeInTheDocument (src/__tests__/router.test.tsx:538:60)

see: https://github.com/redwoodjs/redwood/actions/runs/6032779642/job/16368480189#step:10:342

Originally posted by @virtuoushub in https://github.com/redwoodjs/redwood/issues/9082#issuecomment-1701312672

[Josh-Walker-GM]

I've been seeing this once or twice too :+1:

Eg: https://github.com/redwoodjs/redwood/actions/runs/6038395635/job/16390496793?pr=9104 Eg: https://github.com/redwoodjs/redwood/actions/runs/6040265077/job/16390819253?pr=9058

[virtuoushub]

wonder if this is a better candidate for a integration test rather than a unit? All that mocking of delays in jest seems too synthetic and tricky to get right.

Cypress and Playwright seem like a better place for this type of test imho, even though from what I can tell we might still run into a similar issue; but it seems closer to real world use cases in an integration test than a unit.

• https://docs.cypress.io/api/commands/intercept#Throttle-or-delay-response-all-incoming-responses
• https://github.com/microsoft/playwright/issues/19173#issuecomment-1332652759