What does Automated Integration Testing look like?

Question

I'm aware of the test automation pyramid, unit/integration/gui based automated testing. My question is, what does an integration test look like? I was always under the assumption for the likes of a login scenario we would use GUI automation to handle it, however after more reading I'm not so sure?

Option A

• Prep WebDriver & navigate to login
• Login as the user
• Assert that the user has logged in

Option B

• HTTP GET /Login
• HTTP POST Credentials
• HTTP GET /Index
• Assert that the user is logged in, perhaps their name is in the response body HTML?

Should we be always opting for Option B here? using something like REST-ASSURED and not using Selenium at all in this instance?

How do you decide which to do via the GUI and which via the Service/API layer like this? Obviously to me the API layer seems much more robust, changes to elements on the page will not break the tests etc but on the flip side, how will you know if the login button itself is properly functioning?

Answer 1

The traditional test levels (unit/integration/system/… testing) usually do not make a statement about how the technical implementation takes place. Choosing a proper test interface is almost always a trade-off in terms of robustness, maintenance effort, test coverage, and performance.

If your GUI is not too complex, I would choose option B and test against the API; especially if the GUI code simply adds some glue between the GUI and the API. You can still test the GUI separately with tools like the Galen Framework and/or Selenium.

A related blog post by Alan Richardson suggests the following rule of thumb:

• build a model of the system such that you can identify the integration points and the ‘isolated’ shared functionality.
• Test isolated functionality at the lowest points you can.
• Work back out to higher (or ‘peer’) levels of integration and abstraction and consider the system in terms of integrating systems.
• Look for unique functionality at the higher (or ‘peer’) levels of abstraction, you will need to test them there.
• If you exercise unique functionality in isolation - by mocking out the integrating systems - then you might need to look at this from a technical risk perspective and decide if, or how much, you need to exercise it while integrated.

Answer 2

You can test various components: web service, web GUI, database, etc at different levels: unit, integration, acceptance/functional.

The main thing that differentiates unit tests from integration tests is the context the tests are run in. Unit tests can be run in isolation with no integration of any other components that make up the entire stack, making it easy to run as part of a build directly against the code. Sometimes they are run using mocks to simulate those other dependent components.

Integration tests specifically target integration points between the component and its dependencies. Often, integration tests can't be run directly on the build machine as it may require an actual installed/deployed application, although this is becoming less and less of an issue with the use of containers like Docker where you can create an instance of a container with the application deployed and run tests against it. The advantage of integration tests over full acceptance tests is that you can test much faster and at a much lower level - methods and code blocks (similar to unit tests). If you move integration tests to execute directly against the UI, you aren't really gaining anything and may as well just skip them all together and call those acceptance tests.

From your description and the comments that the GUI is tightly integrated with the business logic I would suggest the following for testing the GUI:

• Unit tests: Javascript unit tests that test specific methods and code blocks within methods.
• Integration tests: Javascript tests run in the context of a functional (or mostly functional) application that includes dependent components (database, web service, queuing api, etc).
• Acceptance tests: WebDriver tests run against the UI