UI tests - are they always needed?

The topic of this post will be devoted to testing, as such, and UI testing of components on client applications, for example, applications using Angular.js and their ilk.

What types of testing are currently most popular for client applications?

1. Unit - basic, I would even say - MANDATORY. level of testing. It is intended to check that all the basic functionality of components, services, etc., is working properly and performs its task.
2. UI - testing the application interface itself, all its whistles and “not bugs, but features”. The reason is that we imitate user actions — clicks, link clicks, and other actions of a similar kind. Its meaning is to check the interaction of components with each other.
3. E2E - performs functions similar to UI testing, but with one BUT, all tests are driven with real services, API, BE.

Since, to force the programmer to write even Unit tests, this is already Sisyphean work, only Spartans from the world of programming get to UI & E2E. And I saw the absence of tests, both in small startups and in large corporations.
')
I myself covered all three types of application tests, but, at one time, I thought: “Is it possible to just cover with more and more Unit tests and a small one - E2E?”. Let's try to figure it out.

The main advantages of UI testing:

• Covers most of the user actions and allows, on the part of the user, to touch the application.
• Checks the interaction of components and services with each other.
• Increases application reliability.

The main disadvantages of UI testing:

• A huge, sometimes incredibly huge amount of time spent on the mock of all components and services (as well as in the Unit tests).
• Not applicable for small-sized applications, because the game is not worth the candle.
• The tests themselves run longer than the Unit, due to the complexity of the services used.
• More complex process of automation and integration into the pipeline (on Jenkins, Travis, etc.)

The first and most important question is to determine the size of your application. If it is small or short-term, you can safely leave UI tests overboard, since Unit + E2E is enough for you.

The second , more important, what to do if you have a huge monster that you just need to check as thoroughly as possible? And the answer is - more Unit tests!

Indeed, in the real world, behind every action is a change in the state of an application or component, be it functional or OO programming, etc. Any user action must end with something, there must be a result. And with the help of Unit tests, you can always check the result of an action, and with the help of E2E, you can check the interaction of components.

Example:

• Use case: The user must log in through OAuth and get on the Hello page.
• App:

  LoginComponent: login: () => { let isLogged = oauth.login(); if (isLogged) { router.changeState('hello-board'); } else { showError(error); } } 

• Test case:
  
  • Unit test: Check whether the login () function was called. If “login ()” was called and Router changed its internal state to “hello-board”, then everything is fine.
  • E2E test: Check if the same “Login” button was pressed and the request for oauth was actually sent and if the user switched to the correct “Hello” page by checking the user's browser string after the request.

PS Open for any comments and it is extremely welcome!

PSS Thank you for your time!