Ranting Tester

Let's say that you already know how to write a test procedure. Or, at least, you know someone who knows how to write a test procedure. You have a pile of manual procedures that are just waiting to be automated. You've chosen your test tool and proven that it works great with your application. Your next hurtle is "how do I structure my test code?" Not the procedure itself, but all the helpers. You need to refer to the same controls (labels, buttons, inputs, drop-downs, etc) many times in your tests. Some of the controls in the application are a little tricky, so you want helper methods to make that easier. How do you organize this code? A great place to start is the Page Object pattern. The idea there is that you have a class (either static or a singleton object) that contains the smarts of how to get to all the elements on that page. Instead of writing a test that looks like this ( α) : Application().SomeNonsense().Container().Element("whoopWhoopElement3zz*...

Are your automated system tests a rat's nest of unmaintainable code? Unmaintainable system test code is usually the result of app-code developers putting their filthy paws on innocent test procedures. There are two keys to writing maintainable system tests - write the test part like a procedure and write the helpers like an object-oriented interface. For now, I want to focus on writing your test like a procedure. Most app-code developers don't like writing linear procedures. They like loops and super-commonized methods with pithy names. As soon as a linear procedure does the same thing twice, they want to pull that out into a common helper method and slap a pithy name on it. You must fight this. Stand your ground! Take their pithy-named helper method and throw it directly in the trash. How do you know when a helper method should go in the trash? Stick to the language of your domain! Stick to the language of your product. Let's look at an example. Let's say that ...

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

I see code review comments and changes in code reviews where developers obviously have this mantra of “don’t repeat yourself” that they speak over and over. Time and time again I’ve seen it lead to some of the worst spaghetti code. The kind of code that makes me want to respond with a brick. Code that is reasonably well structured and written by competent individuals yet still makes no damned bit of sense. Ready for an example? You’ve got a class that is doing the display of a couple inputs with autocomplete. All the previous options come in as arrays. So, someone might write something like this: let option1Initial = option1Value ? [option1Value] : []; let option2Initial = option2Value ? [option2Value] : []; let option1TypeAheadValues = allPreviousOption1Options     .filter((option, index, array) =>          array.indexOf(option) === index)     .concat(option1Initial); let option2TypeAheadValues = allPreviousOpti...

For three years, I owned a 2013 Lincoln MKX. I wanted something that wouldn't have quite the tendency to slide off the road that my rear-wheel drive roadster has and, since I could lease it, I figured it would be a good time to try out a larger vehicle. Also, since it was a lease, what better time to try out all the neat features that so many cars come with? Things like built in nav system, heated steering wheel, bluetooth integration for my phone - the works. So, I got it fully loaded. And, being a huge nerd, I was a bit excited at all the features. Sadly, the excitement evaporated quickly. What does a car have to do with software testing? It's all about design. So many things seem like a good idea at first and, indeed, they are good ideas. But, unless someone takes the time to really understand what it's like to be around that feature every day, conveniences can quickly become annoyances. Love can turn to hate. Desire to disdain. Excitement to petulance. Coke into Pepsi...