This documents aims to give a brief picture about the automation framework development. The design pattern that followed for this framework design is page object model. The main folders in this solution are
- Automation Framework: This solution folder contains the core contents of framework and it consist of a single project called as “Auto Frame”.
- Pages: Pages for each domain is created under different project.
- Each page contains only the web elements and the methods to interact with that particular page.
- Page initialization is taken care by the framework.
- In complex pages there is a clear logical separation between the “test data” logic and the “page” logic.
- Tests: Tests contains only the logic to interact with the pages. Under that project there are different test files like system tests (eg: SystemTest1.cs), Integration test(IntegrationTest1.cs) etc.
- Zet up : This solution folder consists of the Environment setup excel files such as IntialSetting.xlsx, excel1.xlsx etc… and dynamic test data.
Figure 1 Framework Overview
Figure 2 Auto Frame Structure:
Base contains Base.cs, BasePage.cs, BaseTest.cs and DriverBase.cs.
Base.cs is the core of this framework. The most important rule is that Base.cs should be inherited by the BaseTest.cs, BasePage.cs and APIBasePage.cs which in turn should be inherited by the corresponding Tests and Pages folder. There is a middle level of inheritance for the BaseTest.cs. This middle level inheritance is done in order to handle different combinations of Environments and Browsers [aka combination of Test Fixture and Test. The core contents of base class are
- Report variables initialization
- Page Generics – to avoid page initialization for each page.
- Recording variables initialization >> can be controlled through InitialSettings.xlsx.
- One Time Setup: Initialize the report for each “test suite” [not “test case”]. Can create a new report or append on the existing report which can be controlled through InitialSettings.xlsx.
- One time tear down: This will be executed when all the tests are finished in that particular test suite [executed when the tests under similar test fixtures are done,]. Currently this opens up the report generated.
- Setup: Executed for each test case. Handles the recording functionality of the framework. Can be controlled through InitialSettings.xlsx.
- Tear down: Logging the report for each test case. Stops the recording and log it to report if applicable.
- Extent Manager: Extent manager handle the report path & report initialization and decide whether a new report or append on the existing report. This settings can be controlled through InitialSettings.xlsx.
Rule of thumb: All the classes that ends with “Page” should inherit from BasePage.cs. BasePage.cs handles the page initialization for pages.
Rule of thumb: BaseTest.cs should be inherited by BaseTestproject1.cs, BaseTestProject2.cs, which in turn should be inherited by the ProjectTest1.cs, ProjectTest2.cs,
Base Test’s handles primarily 2 things
- Browser Setup: Calling “Setup” method will open the corresponding “browser” in the parameter.
- Can add / delete browsers here.
- Report Setup & start executing TC.
- It’s ideal to call this method from all the “Tests” as it will handle the report initialisation for all the Test types such as SESB, MEMB, iMEMB etc.
API Base Page handles the logic to handle the authentication token.
This class handles the IWebdriver driver. Designed in a separate class to handle all the browser related methods / extension (gotoURL etc…).
Contains mainly three files
- ReportConfig.cs: handles the directory creation for reports, screenshot, screencast etc.
- Settings.cs: Handles the global variables.
- TestEnvironmentSettings.resx: A resource file which handles the visibility of excel, screenshot settings like take screenshot in each step. excel location etc. [Rather than reading this setting from excel file, the following things are created in a resource file as some of them (eg: “Report Screenshot”) are frequently accessed with in the code.]
Extension contain the custom extensions for Selenium WebDriver and Web Element.
184.108.40.206 Web Element Extensions
These are the custom extensions to handle Web Elements. As some clicks can only be triggered by Java scripts custom extensions are inevitable. The extensions developed are
220.127.116.11 Web Driver Extensions
Custom extensions for web driver developed are.
It’s better use a combination for “Wait for page load” and “Wait for element” if the system is too complicated.
Helps for excel operations, Jquery Data Tables random test data etc.
The structure of pages are mentioned previously. Each page will only have the web elements and the corresponding methods to interact with them.
Note: In some page methods there is clear logical separation between test data logic and page logic to avoid the repetition of code.
Tests file contains only two things
- Call the “Start Test” method and pass the parameters to start report engine
- The logic to interact with the pages, for example
CurrentPage = GetInstance().LoginPageifAny() .As<HomePage>().ClickTheLink() .As<Page2>().VerifyPage();
Stores the Test case and Test Data. A quick overview of the files
- InitialSettings.xlsx : Stores the Environments URL’s, Browser Names, Report Location, Report Path, New / Append Report, Record Test
- The excel filenames starting with TC contains the test cases. These excel data are used to assess the test type, logging reports etc. [Note: Any change in Row 1 will stop the test execution.]
- TCData – Folders which starts with TCData contains only the test data.
- DynamicTestData.cs – contains test data that are generated while execution.
** This doc only discuss the bare minimum things about the framework. More details can be found at the code level.
Aadhith Bose 🙂