Ranting Tester

So, last time, I dug into how Selenium blows up if you ask it for something that doesn't exist. I mean, how dare I, the tester, want to care about things that don't exist? If we asked about all the things that don't exist, we'd never have time to play ping pong. Never the less, we are asked to test these nasty requirements about security and privacy and some times you really don't want to show private data to every user that hits your page. So, here we are. Today's Selenium sin is the Stale Element Exception. This is a thing that should never exist. To even understand why it exists, you need to stew yourself in a bath of object references and multi-process timing. That, my friends, is a bath you do not want to sit in. Let me do my best to give an example of why we might see this problem. Let's say you have a web application that displays a dialog to edit a user. You want to make sure a certain user property is displayed on a couple users on the edit ...

I've been using Selenium WebDriver for a few years; because, well, there aren't many other options. If you're doing web work and you didn't get to pick your front-end library from a list of new-hotness frameworks, you're probably using Selenium for your system testing. And you should! It's a good tool. There are, however, a couple of design decisions that make me want to attack Selenium with a comically large hammer made of nails and salt. I should clarify that we're working in the .Net world, specifically with C#. We're using Selenium WebDriver with Chrome (headless and not). If some other version of Selenium fixes this or if there's another tool that does what Selenium does without these issues, then, great - I'd love to hear about it! If it means switching our front end to some specific framework or abandoning certain kinds of tests, then now is the time for you to sit quietly in the back and Tweet about how much you love the sound of your o...