Ari Perkkiö

@jhpedemonte I also run into this issue when using `@cypress/code-coverage`. But this also came up with [`cypress-sonarqube-reporter`](https://www.npmjs.com/package/cypress-sonarqube-reporter). In both cases I was able to add work-arounds by prefixing all configurable...

@gsouf that's best solution for now. I really want to keep Cypress configuration file under a sub directory `config/` since that's where I store configuration files for all sorts of...

> won't behave the same way if the cypress config file is at the root of the app, or in a subdirectory. Relative paths are not managed the same way....

This is not really an issue with `waitForElementToBeRemoved` since element is already unmounted when returned from the query: ```js const content = await screen.findByText("Content"); console.log(content.outerHTML); // Content console.log(content.parentElement); // null...

If `waitForElementToBeRemoved` is confusing the test setup here too much it can be replaced with following: ```js const content = await screen.findByText("Content"); expect(content).toBeInTheDocument(); ``` ``` ● unstable test 199 expect(element).toBeInTheDocument()...

With this setup: ```js const TIMEOUT = 5; // Adjusting this doesnt matter const DIFF = 5; ... useEffect(() => { const timer1 = setTimeout(() => setVisible(true), TIMEOUT); const timer2...

I had some time to debug this further. Looks like this is caused by nested awaits in `asyncWrapper`. https://github.com/testing-library/react-testing-library/blob/a241cb8a417135a529acb5504c83c0889080b8c2/src/pure.js#L12-L18 More debugging info, narrows the issue to asyncWrapper Replace `asyncAct` with...

React's act will [flush micro tasks once given callback resolves](https://github.com/facebook/react/blob/c7b4497988e81606f1c7686434f55a49342c9efc/packages/react-dom/src/test-utils/ReactTestUtilsPublicAct.js#L160-L170). In practice this means that once callback created by `findBy` queries resolves the state of DOM may change before `act`...

@vadeneev and @josh-biddick, it sounds like you have run exactly into this same issue. I'm not sure about @AhmedBHameed's case. I've found one tricky way to identify such unstable tests...

@alessandrocapra without seeing the whole test case + component, or a minimal repro of your specific problem it is difficult to give any accurate instructions. Based on your code snippet...