-
Notifications
You must be signed in to change notification settings - Fork 25k
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
Problems mocking MockConnection error response #12857
Comments
I came across to the same problem. I would recommend to remove all redundant code from repository because it's not clear where to look in. So briefly the problem looks next
and we have next mock response
so I expect it'll log The single way to fix it is to use |
Exactly the same problem also with the latest stable release of angular. Same situation of @fetis . To fix this problem I used:
The solution described into the official testing example HERE is not working. |
Duplicate issue: #13690. #7135 points out that the current working way requires a double cast in TypeScript ( Other than the official testing documentation @Ks89 linked, there is at least one other error in the API documentation at https://angular.io/docs/ts/latest/api/http/testing/index/MockBackend-class.html . Where it also seems to be assumed that responses with code 404 should result in a thrown error rather than a regular response. Fixing this to generate the expected error might break some folks' tests, but think most or all of those tests were wrong to begin with. |
I tried to work around this problem by creating a class extending Response and implementing Error (type declared in types\node): class ErrorResponse extends Response implements Error {
name: any;
message: any;
}
export function mockError(errorResponseOpts: any) {
return new ErrorResponse(new ResponseOptions(errorResponseOpts));
} and then mock error as: mockConnection.mockError(mockError({status: 404})); |
Previously, MockConnection.mockError() only accepted an Error object. However, in @angular/http, unsuccessful Responses are returned on the error stream. Without this change, there is no easy way to mock an unsuccessful Response. This changes mockError() to also accept the Response type. Fixes angular#12857
Previously, MockConnection.mockError() only accepted an Error object. However, in @angular/http, unsuccessful Responses are returned on the error stream. Without this change, there is no easy way to mock an unsuccessful Response. This changes mockError() to also accept the Response type. Fixes angular#12857 Fixes angular#7135
Previously, MockConnection.mockError() only accepted an Error object. However, in @angular/http, unsuccessful Responses are returned on the error stream. Without this change, there is no easy way to mock an unsuccessful Response. This changes mockError() to also accept the Response type. Fixes angular#12857 Fixes angular#7135
Can we get an update on this? #13104 (the fix) was closed without an explanation. I don't think these workarounds are a good long-term solution, though acceptable in the meantime if this is just a priority thing. |
Closing as this pertains to |
Cannot find module '@angular/http/testing' or its corresponding type declarations. [Angular 9] |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
I'm submitting a ... (check one with "x")
Current behavior
Test Repo - https://github.com/mildfuzz/angular-mockError
I am unable to test predicted HTTP error responses. Mockbackend can either send a response with an error code (which my app treats as a successful response in the test environment, but as an error in real world)
I am unable to send status codes with an error response in my tests, so I can not test any error handling my application might implements.
Expected behavior
at least one of the defined test cases passes
Minimal reproduction of the problem with instructions
Test Repo - https://github.com/mildfuzz/angular-mockError
this is a re-opening of issue #7471, which was closed due to lack of repro steps.
What is the motivation / use case for changing the behavior?
To be able to test all responses
Please tell us about your environment:
OsX
Angular version: 2.0.X
Angular 2.1.0
Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
Chrome 54
Language: TypeScript 2.0.3
Node (for AoT issues):
node --version
= 6.9.1The text was updated successfully, but these errors were encountered: