fakeGET holds one answer per path, so a fake answers the same way however many times it's called. That leaves out every test where the point is that the second call differs.
Pagination is the case. Page one comes back with items 1, 2, 3 and page two with 3, 4, 5 — the same item on both, because the backend paginates a moving list. The bug being tested for only exists in how the two answers meet, and there's no way to describe that through the fake system today.
Something like:
await networking.fakeGET("/stories", responses: [firstPage, secondPage])
let first: Result<[Story], NetworkingError> = await networking.get("/stories") // firstPage
let second: Result<[Story], NetworkingError> = await networking.get("/stories") // secondPageTwo things to decide:
- Whether a sequence is its own registration or the existing
fakeGET overloads grow an array variant. The array variant reads better but multiplies the overload set, which is already wide across the five verbs.
- What happens once the sequence runs out — repeat the last answer, or fail the request. Repeating is forgiving and matches how a real last page behaves; failing catches a test that expected more calls than it registered.
The same applies to fakePOST and friends, though pagination makes GET the one that actually needs it.
fakeGETholds one answer per path, so a fake answers the same way however many times it's called. That leaves out every test where the point is that the second call differs.Pagination is the case. Page one comes back with items 1, 2, 3 and page two with 3, 4, 5 — the same item on both, because the backend paginates a moving list. The bug being tested for only exists in how the two answers meet, and there's no way to describe that through the fake system today.
Something like:
Two things to decide:
fakeGEToverloads grow an array variant. The array variant reads better but multiplies the overload set, which is already wide across the five verbs.The same applies to
fakePOSTand friends, though pagination makes GET the one that actually needs it.