Context: On a project (C#/.Net in backend and integration tests, TypeScript/React in frontend) I have complex integration tests that are more like "test scenarios": they test the business logic through the UI and somehow test the functionalities of the UI, for example: it ensures an input field is readonly after having done some modification in the page.
I mainly have 2 issues with those tests:
- Finding DOM elements
Most of the tests describe a scenario but for some reason the testing framework has been designed to represent what is on the page of the frontend. For example, a test might go to a form page for edition and then click on the "Attachments" tab to get the attachments panel and then do some clicks to upload a file.
To do that, I've been asked to modify the working frontend to add a "data-id" attribute on the elements that should be clicked by the integration test. I can't say why but this sounds wrong to me. It feels like I'm going to introduce code (even simple) of the integration tests to the frontend application.
So my first question is: how does everybody usually find their DOM elements?
My concern is that if I actually look for the elements using an xpath or CSS selector I will end up with tests that have a strong dependency on the DOM generated by the frontend while using data-id would probably make it more flexible. So if you decide to change the location of an element, you will break easily the integration tests.
On the other hand, I have the feeling that the tests are describing a bit too well what they are doing and for example they should be simplified from a 3 steps logic Go to attachments > Select file > Click add attachment to a single step logic Call magic helper that will upload an attachment in order to have this logic in one single place.
- Limit of the integration tests
We have backend unit tests, frontend unit tests and integration tests. Integration tests outnumber everything by a factor of 2 or 3 the rest. And I'm not sure that we put the right stuff in those integration tests.
For example all the different login methods are tested by integration test. The account/bad password locking mechanism is also tested by integration test. We don't have/need unit tests at all and most of the time they feel duplicated with the integration tests.
To get more into this example I think the logic of the account/bad password locking should be tested by unit tests while the integration tests should check only the login methods that require an integration with an external service (using Windows credentials for example or OAuth).
But I'm not sure of what exactly I would put where. So my question is: how do you determine if a test belongs in an integration test or backend/frontend unit test? Is there a list of questions you should ask yourself?
Some interesting reading on the subject: Frontend testing: what and how to test, and what tool to use? Especially:
Don't write tests for every small corner case. These tests are expensive to write and take too long to run. You should focus on the cases that explore most of your functionality. If you write too many tests at this level you will probably test the same functionality that you have previously tested on your unit tests (supposing you have written them).
