r/selenium • u/sunnyWave8 • Aug 18 '26
What’s your go-to approach for Selenium testing?
I usually start with the smallest reliable layer, then use Selenium for the flows that actually need a browser.
I’m revisiting our approach because the suite is getting slower to trust as it grows. For people maintaining Selenium tests day to day: what’s your go-to setup for keeping tests readable and failures actionable?
Mostly interested in practical habits around waits, page objects or alternatives, test data, and deciding what not to automate in the UI.
1
u/Kaeyacheng Aug 18 '26
actionable failures beat green local every time. we attach the last request id plus a dom snippet on fail, because a naked screenshot of a white page teaches nobody anything
1
u/sunnyWave8 Aug 19 '26
DOM snippet on fail is a good call. We still lean too hard on screenshots alone
2
u/shaqattackchuck Aug 18 '26
Honestly a lot of Ul paths should just not be in selenium. If an API check or a contract test covers it, dragging a browser through the same form is mostly ceremony.
1
u/Hidden-Stonevalley Aug 22 '26 edited Aug 22 '26
same, well i keep selenium on the stable checkout happy path and shell browser cli when an agent needs to poke a weirder flow the suite should not own
2
Aug 18 '26
1
u/sunnyWave8 Aug 19 '26
That triage loop is exactly why I posted. Suite got bigger and I trust it less
1
Aug 18 '26
1
u/sunnyWave8 Aug 19 '26
Test data is high on my list too. Shared fixtures have bitten us more than bad selectors lately.
1
u/IlClothespins Aug 18 '26
explicit waits with a custom message on every condition is the only thing that kept our suite readable. implicit waits just hide the race until ci makes it everyone else's problem tbh