I tried writing UI unit tests for my GUI apps and I face the problem that, while they work well when I initially write them, they turn out to be brittle and they break whenever the design changes (that is, quite often). I'm struggling to find a set of guidelines that would lead me to having maintainable unit tests for the GUI.
For now, one thing that I discovered is that tests saying "this component should show its input data somewhere" are good (and that's very easy with HTML). Tests checking for a specific state of a specific part of the component are usually brittle. Tests going like click-click-click-expect, that try to follow the user behaviour and the underlying business logic (which is the most important part) usually turn out to be brittle. How do I write good tests?
To be more precise, I'd like to know some patterns about what could I test in my UI, not exactly how to test it. Naming conventions and fixed identifiers are good, but don't solve the core problem, which is, that GUIs change a lot. I'd like to test the behaviours that are most unlikely to change. How to find the right thing to test?