In the last post, I showed a basic code snippet and described a little about how we implement our test scripts for automation. This post will go more into detail about how the underlying objects are implemented.

So, I'll re-post the same script I used in the last one, with some slight changes

First, I should note some of the methods used here: validateFields,update, and assertExists. The title of this post reflects a bit of a flaw here: almost all of our Classes have the same functions... these three and a few others, but there's no way, as there is in Java, to enforce the implementation. It's not a big deal when two or three of us are working on building out these libraries, but it becomes a much bigger deal when we add a 4th and a 5th... oy.

Here's the list of standard methods we implement for each of the 40+ Classes we've implemented:

• Init - a poor man's constructor
• commit - takes all defined attributes and creates the entity within the AUT
• locate - navigates to the entity's representation in the AUT
• validateFields - checks the UI form fields against the defined attributes
• del - deletes the object
• assertExists - asserts, however it can, that the entity has been created in the AUT
• assertDoesNotExist - asserts, however it can, that the entity has NOT been created in the AUT
• submitViaAPI - creates the entity via the API instead of the UI, if available for this entity

Those methods are available, reliably, for every object we've implemented. In addition, each object has a set of methods tailored to that object.oUser.addRole is one such method--allows you to set the permissions for this user in a way that gives them more access. Most of our time is spent filling out these methods, so we can add functionality to our entities and allow complex interactions between them.

If you're using TDS (and you should be), IntelliSense will pick up all the attributes and methods for the Classes, and you'll be able to start writing code for any object without needing studying the code, or even all the documentation we've written. You don't need to know much about coding at all. We have our QA team members request methods where they don't exist. These methods get prioritized and implemented as we see fit, and as the AUT's underlying features stabilizes.

One key here - when the business analysts conduct their usability sessions and get feedback from our user conferences, things frequently change. They add a click here, remove a tab there, and change things all up. Most of the time, all that is required from our library developers is a change in one part of the central Class file, and the test script code doesn't change. That's a point you'll see emphasized time and again as I go through these things.

Anyway, once the test script is written, it gets entered into Rally, our test case repository. More on that in the next post.