Selenium Testing Framework

When writing test scripts, you might find yourself trying to solve similar problems over and over again. So why not re-use the same solutions over and over again? The following framework will help you get the most out of your code without needing to do tons of maintenance every time something changes.

Before getting into specifics, lets first talk about what should be implemented when writing test scripts. At GLG, our tests typically go through a set of steps on the website. They also have to interact with elements on the site in order to accomplish these steps. Then there is the actual tests themselves, which review the displayed content on the site. Essentially, we have tests that assert the content on the site, a set of steps we need to take in order to perform these tests and then the pages with elements that we are checking or interacting with.

When drawn as an ERD, we have something like this:

How can we best make use of this structure? We want tests to focus on use cases, actions that focus on what steps to take, and pages that allow us to interact with them. From a development standpoint, this means we have tests containing a list of actions that can be used to obtain the values required to check or change the state of the system under testing. Actions can interact with pages in order to complete these steps and make sure they accomplished their task. Pages can be used by actions or tests to add, edit, clear, or read data. Adding these relationships to the ERD, we get something like this:

What does this look like in code? How would we best accomplish this task? Well, that depends on what you are doing. For example, maybe you need to test 5 different types of projects, or maybe you need to test same page differently each time. Either way, as a coding standard, you should always design classes with a specific purpose. Anything that is shared should go into a base class for common functionality.