Anything that can go wrong will go wrong. - Murphey's law
Everyone in my team writes UI tests, partly because we built UI-licious, a tool to automate UI testing for web apps.
Is that with the way the testing tools work today, tests are wired to the actual design and implementation of the UI, and quickly become obsolete.
This means that you need to create multiple tests to test desktop and mobile designs for the same test scenario. And whenever the design or code is changed, the tests needs to be updated. It's a colossal waste of time to be going back and forth to fix broken tests.
Plus the use of CSS selectors, XPATHs and magic waits make the test horribly unreadable and difficult to maintain.
Tests should be independent from implementation because it is supposed to test if the implementation follows the specs. It makes no sense at all for tests to be wired to implementation. And why does it even matter what front-end framework - Angular/React/VueJS you use?
What then, does specs mean for the front-end then? The user's journey. That's how your app deliver's value to the consumers.
That's why I ended up creating UI-licious, because:
The UI-licious test engine does the heavy lifting of deciding how to correctly interact with any UI given simple commands, even in ambiguous scenarios where multiple elements are similar. Under the hood, there's some dynamic code analysis and good old-school AI involved to do this.
In any case, front-end code is still code, it changes, it has smells, it has bugs. Is there a good reason not to test it besides the lack of good tools to do so?
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.