$httpBackend.expectGET doesn't fail with undefined url parameter

[llehn]

$httpBackend.expectGET() accepts all GET requests when it's url parameter is undefined. IMHO it should fail.

I have a test where the URL parameter for expectGET() is retrieved from an array. After I renamed the array variable the tests continued to pass, when I was expecting them to fail.

$httpBackend.expextGET(void 0).respond(response);
issue GET
$httpBackend.flush();

does not fail.

Angular 1.3.11, PhantomJS

[pkozlowski-opensource]

@llehn currently undefined means "match any request", including none. What is the exact behaviour you would expect? What do you mean exactly by:

IMHO it should fail.

Which is the method you are talking about? expextGET or the actual call to a GET method (from the production code) or flush? I mean, which one would you expect to fail?

[llehn]

I would expect the test to fail, this may be the GET request or expectGET. I'm very fond of not allowign to make mistakes, so I would put that into expectGET and make it fail when URL is undefined.

Docs state expect* functions are for precise unit tests, where order and stuff matters. Currently all my tests silently pass (wrongly) if you pass undefined to expectGET(). Maybe I would expect whenGET(undefined) to have some special meaning, but certainly not expectGET

Also currently when no request is made, httpBackend.flush() fails. So at the moment expectGET(undefined) only leads to test failure when no request is made and tests pass on all other cases (I don't have multiple GET requests so don't know about this)

[pkozlowski-opensource]

@llehn so, once again, passing undefined means "match all requests" and it is very nice feature to have if you don't care about exact matching of requests. Having said this I saw people "complaining" about this already so maybe we need to update docs.

[llehn]

Yes this does need update in the docs in any case.

I disagree that it's handy because in my case (which is not out of this world) it makes tests pass which should have failed, effectively making them worthless. So to have properly working unit tests you do need additional check on the url parameter, which is not handy. So it's basically just the question where you test for the url parameter - in your unit tests every time, or in expectGET() once.

I'd find something like anyGET().respond(..) natural to read and write instead of expectGET(undefined var or void 0).respond(..)

[pkozlowski-opensource]

@llehn anyGET sounds like a reasonable proposal. Let's put it into the backlog and figure the best course of action here.