According to some software testing experts Selenium is vastly overused by the testing community, to the point of being abused. Some might even say 90% of Selenium tests do more harm than good. The argument is based on the premise that initially tests work as expected but over time the test suite grows, and soon enough most of the “testing” efforts are concentrated on just maintaining them, providing no value to the business – or that the value they provide could be achieved with much less effort.
It has been my experience, too, that E2E tests are very easy to write and extremely hard to write well. They are notorious for being flaky (sometimes they pass, sometimes they don’t even though nothing in the app or tests has changed). They are also hard to debug.
It takes a lot of hacking to make them pass on all browsers and the execution times is markedly slower compared to lower-level tests such as Unit and Integration tests in the back-end.
Today I learned that Jason Huggins’s initial intent for Selenium was to make the Developer’s job easier by automating UI tests on a Limited number of cases, usually to confirm a Bug has been fixed on a couple browsers automatically. At the inception of the tool, the were no CSS selectors and no XPath. (Because there was no need for them, the dev who wrote the UI test could easily add an ID his or herself if needed. ID locators are the fastest and they unmistakably identify the element anyway)
Some say that Selenium was never meant to become an industry.