One subtle issue worth watching is that resetting the mock doesn't automatically guarantee isolation if tests share external identifiers or asynchronous requests are still in flight.
For example, a delayed request from one test could arrive after beforeEach has reset the mock and contaminate the next test's request history or scenario state. I'd make sure each test waits for its interactions to settle before cleanup, and use unique context IDs where possible. Randomized execution catches ordering dependencies, but repeated parallel runs are especially useful for exposing these timing-related leaks.
Mateo Ruiz
One subtle issue worth watching is that resetting the mock doesn't automatically guarantee isolation if tests share external identifiers or asynchronous requests are still in flight.
For example, a delayed request from one test could arrive after
beforeEachhas reset the mock and contaminate the next test's request history or scenario state. I'd make sure each test waits for its interactions to settle before cleanup, and use unique context IDs where possible. Randomized execution catches ordering dependencies, but repeated parallel runs are especially useful for exposing these timing-related leaks.