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