-
Notifications
You must be signed in to change notification settings - Fork 27.4k
ngMock $httpBackend should keep a list of the received calls to debug tests #10596
Comments
@fabiosussetto did you try, in your test: afterEach(function() {
$httpBackend.verifyNoOutstandingExpectation();
$httpBackend.verifyNoOutstandingRequest();
}); AFAIK it should show failed expectations / additional requests. Docs here: https://docs.angularjs.org/api/ngMock/service/$httpBackend |
@pkozlowski-opensource yes indeed, and my test fails with this stacktrace:
And my test was failing because I was calling the wrong url (specifically I was using the wrong id in the url) from my code under testing. I'd love to have a way to immediately see that the expected url was not hit, and instead the wrong url was. |
Not sure what you are proposing, exactly, I'm afraid. Which API call you would expect to fail "immediately"? |
Sorry probably I haven't been very clear. Given my $httpBacked.expectGET() failed because I was calling the wrong url, I'd like to be able to do something along these lines:
and see a list of API calls received by the mocked http backend. That way I could see that I was calling the wrong URL. From the failure message, I only know that for sure I didn't call the URL I was expecting to call, but then I'm in the dark, I don't know if I haven't call the API at all, or if I called it with the wrong URL (or wrong data, or headers). |
@fabiosussetto are you sure that you've got this line in your test: |
http://plnkr.co/edit/zOSCORd25oAtccT6MZ6w?p=catalogue This is my actual test code. Here I'm expecting to call the wrong url, the failure I get is:
Which is fine, I know that I'm not doing a GET to http://localhost:8000/be/rest/timelines/2/timeline. The problem is that I am actually doing a GET to http://localhost:8000/be/rest/timelines/1/timeline instead (notice the wrong id the the url), but I don't see that in the error message. Am I doing something wrong in my test perhaps? If I change line 46 of my plunker to expect the right url (so http://localhost:8000/be/rest/timelines/1/timeline), then my test passes. Btw I'm on angular 1.3.8. Thanks a lot! |
I just tried to swap the two calls to be:
so that it first checks for outstanding requests, but I get the same error message. |
Sorry ignore the previous lines in this comment, it's not true, I get the same error message without the error "No pending request to flush !" |
@fabiosussetto your plunker is not available (pasted a wrong link?) but I was just trying to replicate your issue and it seems to be correctly reporting both URLs on my end: http://plnkr.co/edit/IndYfHohO3KVznUEHdhL?p=preview
Could you please share a plunker that shows your exact scenario? |
@pkozlowski-opensource try to click on the scripts.js file in my plunker and you should see my code, it's not a working example as it depends on a lot of other code, so I pasted just the spec. |
@fabiosussetto yeh, please provide a reduced code example that doesn't depend on any other code - otherwise it is next to impossible to progress on a given issue. |
@pkozlowski-opensource I understand, I'll post something more useful asap. Enjoy New Year's Eve tomorrow night :) |
I totally support more details when failing $httpBackend expectations. Ex. the cryptic "Error: Unflushed requests: 4" : Why can't we access the unflushed requests ? At last their url to give us a lead ? |
+1 for accessing unflushed requests |
With v1.2.25, the installation of an $exceptionHandler can prevent $httpBackend's "Unexpected request ..." exception from propagating out to Jasmine. It doesn't seem to affect other $httpBackend-thrown exceptions. |
+1 for accessing unflushed requests, stacktrace as well. |
Agree.
isn't very informative. I'd like to know what the unflushed requests are. |
+1.
And this is what I get
I'm quite new to ngMock and $httpBackend so probably there is a better way to test this. However, I think $httpBackend should provide an error message with more information |
The current implementation of $httpBackend.verifyNoOutstandingRequest gives an integer number describing how many requests are unflushed. While it's superficially easy to solve test errors from that message by simply adding an additional $httpBackend.flush(), if a developer is truly not expecting the code to make further requests this is not ideal. This change explicitly prints out which additional requests remain unflushed in the error message, helping her determine if the code needs changing, or if an additional flush is appropriate. Before this change: Unflushed requests: 1 After this change: Unflushed requests: GET /some Closes angular#10596
The current implementation of $httpBackend.verifyNoOutstandingRequest gives an integer number describing how many requests are unflushed. While it's superficially easy to solve test errors from that message by simply adding an additional $httpBackend.flush(), if a developer is truly not expecting the code to make further requests this is not ideal. This change explicitly prints out which additional requests remain unflushed in the error message, helping her determine if the code needs changing, or if an additional flush is appropriate. Before this change: Unflushed requests: 1 After this change: Unflushed requests: GET /some Closes angular#10596
The current implementation of $httpBackend.verifyNoOutstandingRequest gives an integer number describing how many requests are unflushed. While it's superficially easy to solve test errors from that message by simply adding an additional $httpBackend.flush(), if a developer is truly not expecting the code to make further requests this is not ideal. This change explicitly prints out which additional requests remain unflushed in the error message, helping her determine if the code needs changing, or if an additional flush is appropriate. Before this change: Unflushed requests: 1 After this change: Unflushed requests: 1 GET /some Closes #10596 Closes #15928
We just merged a commit into master / 1.6 that will make the following change: Before this change:
After this change:
This doesn't cover all cases reported in this issue, only the most requested one: #10596 (comment) Stack Traces for unexpected requests are tracked here: #12231 |
The current implementation of $httpBackend.verifyNoOutstandingRequest gives an integer number describing how many requests are unflushed. While it's superficially easy to solve test errors from that message by simply adding an additional $httpBackend.flush(), if a developer is truly not expecting the code to make further requests this is not ideal. This change explicitly prints out which additional requests remain unflushed in the error message, helping her determine if the code needs changing, or if an additional flush is appropriate. Before this change: Unflushed requests: 1 After this change: Unflushed requests: 1 GET /some Closes #10596 Closes #15928
Hi, I'm not sure if this is already possible, but I haven't found a way yet. In my unit tests I'm using $httpBacked to expect calls to an API. When the expectations fail, it would be useful to see a list of the actual calls, to see you .expectGET('..') failed because your code is calling the wrong url, or is sending the wrong data.
The text was updated successfully, but these errors were encountered: