Let's use a form page for example. I know I should test something like "User fills all fields of the form and clicks submit button, then item is created". But say on this form, there's an integer input. Do I test, for example, what happens when a user enters a letter, a float number, an out-of-bounds integer into this field?
Is this part of E2E testing, or am I going into too much detail that should be left for other tests?
I'm having a hard time drawing the line anywhere but "test literally everything"-- it's easier just to test everything because then I don't have to make the decision on where to draw that line of test coverage. However, total testing time is also a concern of course-- so please help me understand where that line should be drawn.
CodePudding user response：
Unit and E2E tests help each other, you don't need to test every possible error for a single unit of the E2E integration, this is the role of unit tests.
You also need to keep in mind the Happy path and the Unhappy path, this will help you with the test structure. Inside the unhappy path you can handle many scenarios (assertions) within a single test case, like testing for wrong dates and chars in inputs, if you need to have this level of checks in E2E too, so your testing time will not scale too much.
CodePudding user response：
By E2E tests I assume you mean System UI Tests - you deploy an app and run the tests that click on page elements.
The purpose of these tests is to check that everything (HTML JS CSS BE) works fine together. Ideally there should be very few of such tests. So in your use case:
- You need to write unit tests that check what happens when integer/float/etc is specified.
- UI Component Tests (in my terminology these work with mocked BE) - these check that clicking/navigating over the pages works fine. But it doesn't check that UI and BE work together properly.
- UI BE System Integration Tests - testing the layer of UI JavaScript that is responsible to send requests to BE. W/o clicking - just calling the code directly.
- UI System Tests - just a few scenarios that go over all pages once or twice and check that everything is properly integrated.
Most of the time though I see people combining 2-4 in UI System Tests. This leads to much larger system suites though. But even with such approach you should try to move as much of business rules checking to unit tests. And keep System tests to check whether all parts are integrated together.
See: