this is so true. I go even further - for the browser level tests, avoid using “testid” or css classes or anything that is “implementation”, but rely in your te

this is so true. I go even further - for the browser level tests, avoid using “testid” or css classes or anything that is “implementation”, but rely in your test on solely things that the user can read / interact with. So don’t “Press button with id “generate”, but the button that says “save” inside the content element titled “generation”. This way any refactoring work would not require test changes (as it should) and any change of the visible ui / workflow to the user would require an adjustment to the test. This is a style that I learned from ruby’s integration testing framework “capybara”, and have been replicating it wherever I can since. A nice bonus is that if you switch rendering technologies, you can reuse the tests (like react native for example).