This situation can be approached from the possible consequences of failure.
If we talk about the "typical" client app talking to backend services, then usually, front-end is more forgiving than backend is, when a problem arises.
In the end, whatever technology you use in backend, it can have many types of clients, and barely cares about them, whether they are a web app, a native mobile app, an IOT device, etc...
That said, web front-end, unless a terrible mistake is made, is allowed to fail and continue. Should it be? That's another debate. But the strategy on the web is ship fast, fail fast, fix fast, repeat.
A user can easily survive a misaligned button, an ugly interface, a blue screen of death XD (app crash). Even a temporary "I click but nothing happens".
"Restart the computer, phone, app", "use another browser" are half solutions but quickly done and in the hands of the user. Things can be fixed quickly.
Now, for the backend, a "stupid" mistake can bring the whole business to a halt. Data loss or data corruption, that's one thing you don't want. Security breach isn't better and you don't want a core functionality like "payments" to die on you. If millions of users are affected in an instant, that's a serious reputation risk and a business failure.
These were my thoughts about why backend is more tested, or maybe "should be" more tested.
That said, I am more of a front-end person, and I do want apps to be tested. It's quite easy to write unit-tests nowadays. Especially in case of refactor, having good tests in place can save you a lot of time and from realising too late that the wrong data is displayed. On the other hand, E2E tests for the most crucial user stories will save the day far more than people think.
A last thought that comes to mind: the rise and goal of micro-services in backend is to avoid complete failure. The business can continue by allowing non-critical services to fail. Again, this is designing for failure. Tests should reflect where the risks are. It can happen that the front-end value is far superior to the back-end one. Test accordingly.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This situation can be approached from the possible consequences of failure.
If we talk about the "typical" client app talking to backend services, then usually, front-end is more forgiving than backend is, when a problem arises.
In the end, whatever technology you use in backend, it can have many types of clients, and barely cares about them, whether they are a web app, a native mobile app, an IOT device, etc...
That said, web front-end, unless a terrible mistake is made, is allowed to fail and continue. Should it be? That's another debate. But the strategy on the web is ship fast, fail fast, fix fast, repeat.
A user can easily survive a misaligned button, an ugly interface, a blue screen of death XD (app crash). Even a temporary "I click but nothing happens".
"Restart the computer, phone, app", "use another browser" are half solutions but quickly done and in the hands of the user. Things can be fixed quickly.
Now, for the backend, a "stupid" mistake can bring the whole business to a halt. Data loss or data corruption, that's one thing you don't want. Security breach isn't better and you don't want a core functionality like "payments" to die on you. If millions of users are affected in an instant, that's a serious reputation risk and a business failure.
These were my thoughts about why backend is more tested, or maybe "should be" more tested.
That said, I am more of a front-end person, and I do want apps to be tested. It's quite easy to write unit-tests nowadays. Especially in case of refactor, having good tests in place can save you a lot of time and from realising too late that the wrong data is displayed. On the other hand, E2E tests for the most crucial user stories will save the day far more than people think.
A last thought that comes to mind: the rise and goal of micro-services in backend is to avoid complete failure. The business can continue by allowing non-critical services to fail. Again, this is designing for failure. Tests should reflect where the risks are. It can happen that the front-end value is far superior to the back-end one. Test accordingly.