Can't respond to $httpBackend expecations in ngMockE2E

[elnur]

I can define expectations for ngMockE2E's $httpBackend the following way:

$httpBackend.expectGET(url);

At the end of my Protractor tests I can check whether expectations have been met:

$httpBackend.verifyNoOutstandingExpectation();

But I can't set a response on an expectation. This doesn't work:

$httpBackend
    .expectGET(url)
    .respond(response);

My current solution is to define an expect method and then a when method:

$httpBackend.expectGET(url);
$httpBackend
    .whenGET(url)
    .respond(response);

Now, this works, but it's ugly because I have to define a when for each expect.

[btford]

/cc @juliemr

[ExplodingCabbage]

One nasty side effect of this is that when somebody new to the framework is first trying to get their head around unit and e2e testing with the two different mocking modules, if they are foolish enough to copy and paste their $httpBackend.expectGET(...).respond(...) calls from their unit tests to their E2E tests, requests to those URLs get swallowed silently without any indication to the programmer of what they have done wrong.

I lost an hour to just such a silly mistake, and I'm guessing this guy did too:

Mental note: expectGET = unit tests, whenGET = e2e gaaaaah #angularjs #failoclock

Looking at the code, it seems like the expectFOO methods only even exist on the E2E version of $httpBackend by accident or apathy; there is a createHttpBackendMock function used for creating both versions, and nobody bothered to stop it from adding the expectFOO methods to E2E instances.

There seem to be two reasonable solutions:

1. Remove the expectFOO class of methods from the E2E version of $httpBackend - or perhaps better still, provide an implementation of them that, if called, throws an error explaining that verifying that specific requests occurred is not supported in ngMockE2E and that the coder may wish to create a backend definition with whenFOO instead.
2. Implement sensible functionality for these methods.

I'd've voted without hesitation for option 1, but the fact that there's apparently just enough working functionality here that some people like @elnur have managed to bend it to their purposes means that option 1 is a breaking change. So I hesitated. But in favour of 1:

• @elnur's use case is still going to be irritating and difficult for people like him to implement even if the expectFOO functions are fixed (see http://stackoverflow.com/questions/24419310/how-to-verify-httpbackend-mock-expectations-in-a-protractor-test for further hoops that need to be jumped through to call verifyNoOutstandingExpectation() from a Protractor test).
• what 'sensible' behaviour would be of the E2E versions of expectFOO is non-obvious. In the unit testing version, the order in which expected requests come in is important. This is entirely reasonable in the controlled environment of a unit test. In the E2E version, however, the order may be subject to race conditions due to asynchronous events like real ajax requests or animations happening in the browser, such that requiring expectations to be fulfilled in the order in which they were registered is too limiting. Do we change this behaviour or keep it as it is in the unit testing version? One way is a breaking change that makes the API more confusing; the other way actively harms the methods' usefulness at serving their only use case.
• the expectFOO methods are conspicuously absent from the E2E $httpBackend docs, and their obviously-broken behaviour as described in this issue has probably deterred most people from trying to use them.

I do think that @elnur's use case - wanting to check, in a Protractor test against a mock backend, that some particular POST was made to the server - is legit and there is some value to supporting it. But I also think that the expectFOO methods represent a horrible way of trying to serve that use case. Wouldn't a simpler (for the user) and more flexible way be to add a method into Protractor that lets it get a log of the requests the mock backend has handled, and let the testing code make whatever assertions it likes about them? Would such an approach even be possible?

After thinking it through, I remain a cautious advocate of nuking the expectFOO methods from the E2E version entirely; I think the confusion they cause outweighs the limited value they have, and the only use case they're currently serving could be handled much better with a completely different approach.

Am I missing anything?

[elnur]

After several failed or ugly/hacky attempts of making this approach work, I decided to stop using $httpBackend for Protractor tests and went with hock. I did that after realizing that Protractor tests were run in Node and I could as well use a Node library to define HTTP expectations. This approach is much clearer compared to addMockModule() hacks.

I doubt there are a lot of people mocking out APIs for E2E tests because most people just write tests against a real API. Since I'm a hardcore (expert) TDD/BDD guy with a lot of experience on the topic on Java/PHP projects, I tried to bend $httpBackend to my will to write E2E tests the way I feel on the gut level they have to be written. Most people either don't write E2E tests at all or write them against a real backend server. So I wouldn't worry about breaking backward compatibilty here. After all, I couldn't find any examples of doing that on the Web. Basically, I invented this approach myself and I hope it didn't spread.