redundant, we just asserted that it’s0

we just asserted on this withtoHaveBeenNthCalledWith

this comment doesn’t add anything imo

same here.waitFor is already the name of the function being called.

I feel like this setup is a little fragile. I've never stacked multiple calls tomockResolvedValueOnce onto the same spy before, but if I'm reading it right, it means that, no matter what we actually call the function with, we'll always get page 1 for the first call, and page 2 for the second call. But then:

• Any future calls immediately go back to the actual non-mocked version
• We never check the inputs for the functions to decide what to return out. If we accidentally pass page 3 in, we might get page 1 or we might get page 2
• If we try to get page 1 multiple times, we can't

I don't know all the details, but I know that MSW has tools to mock out the API response. Maybe that's not needed and we could keep the Jest Spys, but I think I'd rather make it so that we have a mock that stays locked in for the duration of the test, and then checks the page input:

• A page value of 1 always gives back page 1 content
• A page value of 2 always gives back page 2 content
• Any other page values just give back an empty array

I know you have the checks for the exact inputs a little bit below, but if the React testing tools ever add double-rendering to help check for correctness (like what you get withStrictMode and dev mode), that would immediately cause this test to break

Not sure if I got it. Let me share what I understood.

The issue with this test is it is using stackedmockResolvedValueOnce to mock the responses for the first and second calls so, if react renders twice in the same page, the test would break. Is that right?

Yeah, if React ever double-mounts the same hook for the data fetching, this will happen if we start at page 1:

1. The page component gets mounted, and we trigger the data fetch, using a page value of 1 as input. The function is mocked, so we always get the page 1 data back no matter what
2. The render completes
3. React unmounts and re-mounts the component from scratch, which potentially causes a second data fetch, still using a page value of 1 as input
4. But because we've already popped off the first mock, calling the function with a page value of 1 actually gets us page 2's data, because the mock doesn't actually check what number gets passed in
5. We get back page 2's data, and render that out. React considers the render "stabilized"
6. We go back to the testing/assertion logic, and the tests fail because the page 1 content is no longer on screen
7. If we were to keep going, and try switching the page value to 2 by clicking the UI, we have no more mocks left, and the call goes to the actual API implementation

Updated thespyOn to use themockImplementation, wdyt?

one last thing, I thinktoHaveBeenLastCalledWith would be better here. to michael's point: how many times this function actually gets called could be considered an implementation detail of react. but we do know we want it to have been called, and that at least the most recent call should match this assertion.

https://jestjs.io/docs/expect#tohavebeenlastcalledwitharg1-arg2-

Makes sense! 👍

same thought here