Should front-end integration tests make HTTP requests?

Question

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?

Answer 1

It is useful to have automated functional tests that test the front-end while mocking away the server, but they are not integration tests. They still test a component in isolation, nothing is integrated. They are functional tests of the component.

To qualify as integration test, the test should test that all the components of the final solution integrate, that is work together. For this it needs the complete setup. With the real server and real database loaded with realistic sample data and no mocks at all. You do want to have such test.

The integration tests (of the complete setup) are the most important. They test all the code that will be involved and you should do that before you put any trust in the application. What other tests you want is a matter of balancing the effort to create them with the benefit they bring. The main benefit of tests of individual components is that they allow easier debugging than the integration tests, so write those tests that help you in debugging. Which they are depends on complexity of setting up the various components and is therefore specific to the project.