You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the same request returns different data during different invocations, replayer has no way of differentiating between the two invocations. This can happen when, for example, a resources is fetched using a GET request, it is modified using a PUT request, and it is fetched once more using a GET request to verify that it was updated successfully.
One could add an option to replayer that enumerates the identical requests: It would count how often each request hash has occurred and store fixtures including their number.
As an example, let's assume that GET /foo's hash is abc123 and PATCH /foo … is def456`, and we do three requests:
GET /foo
PATCH /foo …
GET /foo
There would now be three fixtures:
abc123-1
def456-1
abc123-2
Of course, this wouldn't work in every use case, but AFAICT it solves all basic "read, modify, read again" use cases.
The text was updated successfully, but these errors were encountered:
One could add an option to replayer that enumerates the identical requests: It would count how often each request hash has occurred and store fixtures including their number.
As an example, let's assume that
GET /foo
's hash isabc123
andPATCH /foo … is
def456`, and we do three requests:GET /foo
PATCH /foo …
GET /foo
There would now be three fixtures:
abc123-1
def456-1
abc123-2
Of course, this wouldn't work in every use case, but AFAICT it solves all basic "read, modify, read again" use cases.
The text was updated successfully, but these errors were encountered: