-
-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mocked fetch response cannot dynamically change HTTP status, status text or headers #116
Comments
would be nice indeed to have that ability |
@yormy This missing feature was a deal breaker for me; I needed to test successful endpoint responses and failures. I ended up writing my own Storybook wrapper around the fetch-mock library. |
@JohnAlbin your code only mocks fetch, but Angular uses XHR, so it's important to note that it's not compatible with Angular apps. Unlike this module =) |
And yeah, this module is mockingly powerless to do real mocking. Can't set headers etc, that's just pathetic. |
Fair enough. But if an app needs XHR mocking, it's pretty clear
Don't be unkind. Just because |
Well, after I invested time into integrating this module, it just doesn't work for anything beyond simple things. That's quite unkind from the module. Imagine you take a car, it goes 10km and stops middle-way. Not what you'd expect ;( That said, I appreciate the time @nutboltu spent developing this and making it open source. |
Added MR for customized status code returns |
I've just added a PR for adding response headers option support |
When mocking fetch responses, we should have full dynamic control over all aspects of the Response object, including:
Currently, we only have this:
response
to a function)Example use case
I have a fetch endpoint that various authentication tasks and they all use the same URL; the endpoint returns different data, status codes and headers depending on the request body.
In one story, I have a page component that needs to have the client credential request respond with HTTP 200 immediately followed by another request to the same endpoint that should respond with HTTP 500 (mocking a user validation error).
The text was updated successfully, but these errors were encountered: