Skipping anything you feel is obvious/etc, do you think there are any noteworthy gotchas i should know?
Appreciate your input!
Also, I would definitely look up Selenium's implicitWait functionality, as that can fix a lot of "timing" issues within front-end tests. FluentWait is pretty awesome as well (In the past, I have actually implemented my own FluentWait that was independent from the Selenium libraries, because it was so awesome).
If your app supports multiple browsers, make sure you run your tests on all of them when developing -- I can't count how many times I have gotten a test to run reliably with Firefox, only to find out it is broken on Chrome.
Also, for the love of god do NOT use record/playback to generate your tests. The code that it creates, while a time-saver in the short run, is an absolute nightmare for maintenance. (at least it used to be, I haven't used it in the past two years).
Credit: 2+ years writing automated tests, and experience building three separate Selenium test frameworks in two different languages.
1. the biggest bang for buck that we got was the ability to pinpoint which tests to run to exercise which feature. Use as many tools or strategies as you can to make slicing and dicing combinations of tests easy.
2. Think like React and keep everything relevant to a test close to each other with minimal separation into layers. Initially, we split data into a data layer (excel spreadsheets,) UI verification and navigation logic into a package, and a very thin test driver wrapper which pulls all this together. It quickly became very hard to determine what to focus on when tests failed. We have now started migrating to Cucumber where everything is nearby so test failures are easy to debug.
3. Write as little code as possible -- this is generally good advice for all s/w projects
4. Distill UI actions into their lowest level components and expose them as primitives. By this I mean expose things like "open URL," "click X," "Put text there," "Check CSS attr" as primitives. After this, each test is just recipes containing primitives.
* Don't treat your test code as second class citizen. For tests follow the same clean code principles you are following for your app code.
* I saw many dirty workarounds for selenium tests that didn't behave as expected. In major count of it happens due to lack of understanding selenium / test framework API. So read the docs. If something doesn't work - read the docs again ;)
* Don't test everything with selenium E2E tests. Test this way just most crucial scenarios. Leave more detailed stuff to unit tests.
Is making points and adjusting them into counterpoints means a discussion is maintenance of some idea one wants to share, or is it just weird wordplay on your part?