A rapidly and ever changing UI, is it worth having a UI based E2E Test?

[sebastian_solidwork (Sebastian Stautz)]

@rishvaamin

I think since the UI keeps changing and causing false alarms, it might make sense to focus more on stable API-Integration tests.

I support this in relation to literal “End to End” and quote myself from this other thread:
https://club.ministryoftesting.com/t/what-makes-automated-tests-checks-flakey/72173/17

@sebastian_solidwork

I find “End 2 End” being done by GUI very wasteful. I know that is often a escape path for check automaters without much support for testability of the product.
Welcome to automation hell if you lack time to adapt the automation to the changes in the UI … I have been there.

In my current project we check most business logic via API. And the GUI part is more about “Does the UI works at all”, which includes the connection to the server.
The API parts needs around 1,5 hours and is quite stable in terms of check code calling the application. The GUI parts runs in around 10 minutes.

Think it like this: Your automation checks the application BY (and including) the GUI. The automation takes the GUI as interface while the very nature of Graphical User Interface is to be used by humans.
Surely you should check the GUI itself and its integration with the server. But for business logic you could APIs as well.

I suggest to think about what you try to achieve with what automation.
For what is the current automation used and what could potentially changed in the future.
(Sometimes automation is used to counterbalance bad testing / bad test processes, finally distrust.)