6

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?

  • I posted this question on Programmers rather than SO because it's not really a specific issue with code. But happy for it to be migrated if people think it would be better placed there. – James Allardice Feb 18 '14 at 10:03
  • This is the correct place for the question. – Jan Hudec Feb 18 '14 at 10:19
4

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.

  • Straight to the point regarding Unit & Integration tests.. – Anuragh27crony Feb 20 '14 at 9:03
  • "test that all the components of the final solution integrate" - how does this differ from an end-to-end test? – icc97 Feb 12 at 8:35
  • From the Google Testing Blog: "An integration test takes a small group of units, often two units, and tests their behavior as a whole, verifying that they coherently work together." – icc97 Feb 12 at 8:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.