How are integration tests written for interacting with external API?

This is more an additional answer to the one already given:

Looking through your code, the class GoogleAPIRequest has a hard-encoded dependency of class Request. This prevents you from testing it independently from the request class, so you can't mock the request.

You need to make the request injectable, so you can change it to a mock while testing. That done, no real API HTTP requests are send, the live data is not changed and you can test much quicker.

I've recently had to update a library because the api it connects to was updated.

My knowledge isn't enough to explain in detail, but i learnt a great deal from looking at the code. https://github.com/gridiron-guru/FantasyDataAPI

You can submit a request as you would normally to the api and then save that response as a json file, you can then use that as a mock.

Have a look at the tests in this library which connects to an api using Guzzle.

It mocks responses from the api, there's a good deal of information in the docs on how the testing works it might give you an idea of how to go about it.

but basically you do a manual call to the api along with any parameters you need, and save the response as a json file.

When you write your test for the api call, send along the same parameters and get it to load in the mock rather than using the live api, you can then test the data in the mock you created contains the expected values.

My Updated version of the api in question can be found here. Updated Repo

One of the ways to test out external APIs is as you mentioned, by creating a mock and working against that with the behavior hard coded as you have understood it.

Sometimes people refer to this type of testing as "contract based" testing, where you can write tests against the API based on the behavior you have observed and coded against, and when those tests start failing, the "contract is broken". If they are simple REST based tests using dummy data you can also provide them to the external provider to run so they can discover where/when they might be changing the API enough that it should be a new version or produce a warning about not being backwards compatible.

Ref: https://www.thoughtworks.com/radar/techniques/consumer-driven-contract-testing