I am developing a single-page web application using AngularJS. Data for this application is consumed over a REST API which is well tested in its own right.
The Angular application has a bunch of unit tests that test e.g. individual controllers and their methods. It also has a bunch of integration tests that currently verify that those controllers behave correctly when applied to a view.
Both the unit and integration tests are currently sharing a set of stubbed JSON data that is returned when certain HTTP requests are about to be made (by way of the
$httpBackend Angular service). No actual HTTP requests are sent to the API server during testing.
Is this a good approach for front-end integration testing? The way I see it, the unit tests are testing small units of code (such as individual methods in controllers) and the integration tests are testing the way those units behave in the wider context of a view or template. The setup allows the front-end application to be tested completely independently.
However, the developers of Protractor (the integration testing framework I'm using) have stated on numerous occasion that they believe integration tests should make HTTP requests to a real server (see this GitHub issue):
Protractor is intended for end to end tests, so the primary use case is when you have an actual backend hooked up.
Assuming the answer to the above question is "yes" (or "maybe"), should there be a third set of tests that do actually test the communication between front-end application and REST API?