[krystiangw]

I was dealing with Selenium tests a lot. I noticed developers are often skeptical about these tests saying it is not reliable. I do not agree with that, I have proven in several projects that you can have stable and reliable selenium tests. Just like any other tests, it requires proper test environment and continuous maintenance. The most common mistake I noticed is using `browser.sleep` instead of `wait.until`

[notheguyouthink]

Any other advice you'd give? I need to get testing up to snuff in a shop i recently joined and part of that involves frontend tests (something i've not done before). I fear making unstable Selenium tests.

Skipping anything you feel is obvious/etc, do you think there are any noteworthy gotchas i should know?

Appreciate your input!

[saimiam]

Not the guy you think (kristiangw) but I thought I'd jump in because I was in a similar situation

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.

[holtalanm]

The reasons for failures this artcle outlines are all pretty good. Weak selectors will get you into trouble pretty quick.

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.

[krystiangw]

Few more thoughts from me:

* 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.

[saurik]

A car that requires "continuous maintenance" is one I would call "unreliable".

[biot]

Is a driver unreliable because they have to continuously adjust the steering wheel due to changes in the road? Is testing software unreliable because it has to continually adjust due to changes in the functionality of the software it tests?

[elmigranto]

> Is a driver unreliable because they have to continuously adjust the steering wheel due to changes in the road?

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?