I don’t think there is any doubt that this is a unit test:
You have a function, and you’re testing that the function returns what you think it should return. A code base probably has lots of this as they are easy to write, useful, and not flakey.
I also don’t think there is any doubt about what an end-to-end test is. The quintessential end-to-end test is like “go to this URL, fill out this form, click the submit button, and see if the right thing happens. Cypress is king here.
Unit and end-to-end tests are the extremes on two sides of a spectrum. On the left, unit tests, little itty bitty sanity testers. On the right, end-to-end tests, big beefy (cough; sometimes flakey) tests that prove that lots and lots of systems are working together as intended and what a user experiences is in good shape. Even though the amount of code in the test isn’t super different, what is being tested is wildly different.
I think integration tests are a dot somewhere in the middle of that spectrum.
Integration tests combine multiple systems in your app. API tests seem like a quintessential example to me. You could certainly unit test parts of an API, but tests that use the API as you would actually interact with it in your web app are the juicy onces. Meaning combining multiple systems. Integrating systems, as it were.
Say your API is in GraphQL and your front end uses Apollo Client to interact with it. An integration test could be…
- Spin up Apollo and have it connect to the same GraphQL server the current environment uses (dev, staging, prod, etc)
- Write a query and/or mutation that hits the API and does something
- Test what you get back
- … in Jest or whatever.
Now you’re testing a limited set of multiple systems and that’s an integration test.