UI Test Automation Framework proposal with SeleniumBase!

Considering to use Seleniumbase.io for my next web automation framework I decided to come up with an initial architecture diagram that illustrates the integration of the framework with the rest of components. Using Python Webdriver (SeleniumBase) and pyTest.

In this case we will be using the PageObjectModel which is commonly used as a first approach for web testing frameworks:

So let's elaborate a little bit further on each of the specific components:

SeleniumBase

Will serve as our default WebDriver wrapper, which will be in charge of most of the UI interactions, assertions and eventually reporting and logging.

Utilities/WebDriverWrapper

Will be used to wrap those custom UI interactions that are not supported by SeleniumBase, but still will be used across many of the pages and test cases.

DataWrapper

Will centralize the test generation and serving process for all the test cases and keywords (common flows), so that we ensure that no hardcoded data will be generated at different stages of the test process.
The data could be anywhere from api services, json files or random generated data.

Keywords (common flows)

Will contain user flows or actions that need interaction with at least 2 pages objects and that is commonly used across different tests. This will help us reduce code duplicity and eventually build a repository of keywords that could function as blocks to easy build new test cases.

Base Page and Page Objects

BasePage will initially just be added as a placeholder in case we require it. Notice that not all the pages inherit from it, as we want to avoid the jungle inheritance problem.

The page objects will follow the pattern of providing locators and user actions that are available for specific pages.
Note: We could eventually split the locators under their our classes, but initially that would be an overhead.

Base Test Case and Test Cases

Finally our test cases layer. At this point is where we are going to define our test cases structure based on actions or elements delivered by each of the PageObjects. Also at this layer only is where test assertions are executed.

Final thoughts

Of course there is a lot of room for changes with this approach and we will be seeking for feedback on improvements. But overall based on lessons learned and trying to follow a single responsibility principle we think this initial architecture will let us:

• Start writing valuable test cases soon.
• Avoid over engineering issues.
• Heavily rely on SeleniumBase to drive most of the element interactions.
• Be mindful about classes responsibilities and code re-usabilities problems.

Anything else we are missing.