Ranting Tester

Now that you're on board with the Page Object pattern, you're wondering how this could possibly get better, right? There's one more stop on the happy train to System Test Town. We need to go beyond grouping helper methods. It's time to start modeling our application using our system tests. Page Object Problems The Page Object pattern starts to get confusing when there are multiple similarly-named pages or screens in your application. For smaller applications, this isn't as much of an issue. If your application is decently large, however, this is more likely. Each area of the application might have a Reports page, for example. If the reports pages have similar sounding names but different functionality, you'll wish you could differentiate them better. Page Objects also don't help us deal with complicated controls. If you have a grid in your application, for example, you might end up with lots of single purpose methods such as FilterByDocumentNameThenC...

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