How to do unit/integration/end-to-end tests with 3rd party APIs (backend)?

[codihuston]

Refs: https://medium.com/@axelhodler/integration-tests-for-third-party-apis-dab67c52e352

[codihuston]

Mocking the google API response would probably be easier to implement. Really, need to only test the functionality of Gairos against a stub of the Google API... Which would probably make this more of a unit test.

Anything that needs to interact with out the Gairos API can be integration tested on its own...

[codihuston]

Unit tests were added as of : 0ae2350 and b6623c9

[codihuston]

E2e graphql server testing examples: https://blog.logrocket.com/writing-end-to-end-tests-for-graphql-servers-using-jest/

[codihuston]

E2e would test all of the app as if you were an end user. You would likey mock out any external services (backend 3rd party api responses, maybe database connections etc... it really all depends)

[codihuston]

If you would like to do e2e testing across both the front and back end, it may be ideal to use the CDC approach.

If not, you would generally peogramatically query the app individually, and ensure that it responds a certain way. You may implement services, like databases, in these tests.

I.e.) use an http client to query an endpoint, and ensure that the response body is what it is expected to be. You may use any external services (database, etc.) If you can. Ideally, you should (but do not include the front end. If you decide to go that far, it looks like CDC is the way to go).

[codihuston]

https://docs.pact.io/faq

What is Pact good for?

Pact is most valuable for designing and testing integrations where you (or your team/organisation/partner organisation) control the development of both the consumer and the provider, and the requirements of the consumer are going to be used to drive the features of the provider. It is fantastic tool for developing and testing intra-organisation microservices.

What is Pact not good for?

Testing APIs where the number of consumers is so great that direct relationships cannot be maintained between the consumer teams and the provider team.
Performance and load testing.
Functional testing of the provider - that is what the provider’s own tests should do. Pact is about checking the contents and format of requests and responses.
Situations where you cannot load data into the provider without using the API that you’re actually testing (eg. public APIs). Why?
Testing “pass through” APIs, where the provider merely passes on the request contents to a downstream service without validating them. Why?

[codihuston]

Implemented unit + integration as of: 46ac50a

Placing on hold for e2e