I don’t think there is any doubt that this is a unit test:
function sum(a, b) {
return a + b;
}
test('adds 1 + 2 to equal 3', () => {
expect(sum(1, 2)).toBe(3);
});Code language: JavaScript (javascript)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.
it('adds todos', () => {
cy.visit('https://todo.app.com')
cy.get('[data-testid="new-todo"]')
.type('write code{enter}')
.type('write tests{enter}')
// confirm the application is showing two items
cy.get('[data-testid="todos"]').should('have.length', 2)
})Code language: JavaScript (javascript)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…
- In JavaScript…
- 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.
Highly related:
So, I tend to think about tests slightly differently. the classic 3 test types (unit, integration, end-to-end) explain how much you want to test, but I prefer to think of things as developer, consumer, and user tests. With that mind set, you can test things based around how someone would interact with a thing.
Your developer tests are to make sure that they can interact with components, functions, classes as expected and are generally unit tests. A consumer test would be to test the api, and make sure the interface to how it is consumed works correctly. This can be either a unit test and/or an integration test. The user tests do things from a user’s perspective. clicking buttons, navigating pages, etc. you can also do these as unit, integration (single component that makes a call out to the api, but not on the actual page) and/or end to end tests.
As a QA, there is much more documentation one can find out.
For the basics, the ISTQB define a quadrant to help QAs classify tests, more here : https://tryqa.com/what-are-test-pyramid-and-testing-quadrants-in-agile-testing-methodology/
You may know the Test Pyramid as well, as it help guide the test effort on a relationship with the cost: an UT cost less than an E2E, is easier and quicker to maintain and update.
And speaking of API is excellent, because we can do both E2E and Integration Test on them.
• Integration tests will focus on each points, and QA will create Test Cases with various parameters to test than the right error are thrown when bad parameters are given, test limits (INT or DATES boundaries, behaviours with undefined or null, etc)
• E2E test will establish scenarios using various end points on a more realistic situation, for example, based on what are the expected behaviours of the other part (the one using the API) or the end user will do. It check that the software behave coherently regarding the scenario, that the API gives enough capabilities (there is no missing function i.e. the divide operator for a calc), and there is not un detected performances (the software become laggy or unresponsive because of a certain suite of api call are performed)
Both IT and E2E are interesting and tries to tests different aspects of the software.
ISTQB : https://www.istqb.org/