ATSF components and features
Agenda
- Components
- Features and usage examples
- Latest added features
- Future
ATSF - Automation Testing Selenium Framework developed in CTCo for:
- writing automated UI Tests faster, better and more conveniently
- maintenance and support from AUT team
Components
Features
Creating own types of web elements
The problem with WebElement interface:
- is not very handy when working with more complex elements (e.g. all kinds of dropdowns)
- provides redundant functionality (e.g. .getCssValue())
- not possible to extend and add your own web element methods

Using plain WebElement interface
The solution
Decorator Pattern
- is used for decorating objects in the page class
- wraps WebElement and implementing web element interactions with the page necessary to our way

- Increased readability - looking at the type of the field, immediately it becomes clear that it is ComboBox

- Code duplication reduction
- The ability to add your own methods, e.g., clearAndType () to enter the field;
ATSF currently supported custom web element classes:
- Button
- Checkbox
- Combobox
- Label
- Link
- RadioButton
- TextBox
Overriding default ATSF implementation


NOTE -
- Your implementation of a decorator should implement corresponding decorator interface and extend UIElementImpl class
- package hierarchy should match with ATSF`s . E.g. - my ComboBoxImpl is located in toolkit.controls.impl package
- don`t forget to import correct class in Page Object
Element waiting out of the box
Features
- ATSF framework handles waiting for web elements out of the box
- Most of the waiting is implemented in UIElement and Model classes
- In latest versions of ATSF only explicit waiting is used (implicit waiting was completely removed)
-
Every decorator extends UIElementImpl class, which in turn is the base class for manipulating with web elements and have all base methods


- before doing any action on web elment, ATSF will explicitly wait for a element to be present on the page or will throw TimeOutException if it will exceed wait.explicit setting
Waiting for Progress Bar to Dissapear
- provide WaitMode.AJAX as a parameter to a click() method. This will ensure that Progress Bar has dissapeared after the click

- ATSF provides waitProgressBarIsHidden() method based on progress.bar.locator setting from config.properties. Method is part of base Model, from which all models(Page Object) should be extended from

Always use explicit wait. Forget that implicit wait exists.
-
Explicit wait:
-
documented and defined behaviour.
-
runs in the local part of selenium (in the language of your code).
-
works on any condition you can think of.
-
returns either success or timeout error.
-
can define absence of element as success condition.
-
can customize delay between retries and exceptions to ignore
-
-
Implicit wait:
-
undocumented and practically undefined behaviour.
-
runs in the remote part of selenium (the part controlling the browser).
-
only works on find element(s) methods.
-
returns either element found or (after timeout) not found.
-
if checking for absence of element must always wait until timeout.
-
cannot be customized other than global timeout.
-
Therefore, implicit waiting was removed from ATSF framework and now uses only explicit waiting

- wait.normal and wait.before.after.ajax settings were removed from config.properties
- new wait.explicit setting was added (usually set to 5 seconds)
- REMINDER: Avoid using thread sleep at all cost and use explicit wait instead
Driver Factory and Selenium Grid Support
Features
The problem:
- maintaining and passing around a WebDriver object across different tests is a delicate process
- complexity increases when we have to maintain only one instance of a WebDriver through out the test run
- ATSF framework includes WebDriverFactory interface
- includes methods for managing driver instance throughout the test run
- support for parallel execution by assigning drivers to corresponding Grid nodes
- WebDriver instance is thread-safe by using ThreadLocal (shared piece of data to be accessed by only one thread at any given time)
Features
- UIElementImpl class is a base class for all custom web element decorators
- Model class is a base class for all Page Objects (Models)
- both can be also considered as useful helpers for web element decorators and page objects
Lot`s of useful methods out of the box
UIElement interface useful methods
-
WebElement getElement();
- returns WebElement instance of the decorator, so you can work with plain WebElement if needed

-
boolean isExists();
-
handles exceptions:
NoSuchElementException and
TimeoutException
-
handles exceptions:
-
Useful explicit waits:
- waitForElementToBeClickable(int timeOutInMiliSeconds);
- waitForElementToBeDisplayed(int timeOutInMiliSeconds);

Model class useful methods
- waitForCondition(Predicate<WebDriver> predicate, int waitTime, String errorMessage)
- waitForCondition(ExpectedCondition<WebElement> condition, int waitTime)
- waitProgressBarIsHidden()

Features
- Group tests by Features and Stories
- Link to Jira issues
- store logs, attachments, steps, parameters
- screenshot attachment support out of the box
Readable Allure reports out of the box
ATSF Latest added features
- Each page object method should return itself - fluent approach
-
Each page object should be extended from Model. Model is like a helper with additional explicit waits and other goodies
- Hence, while creating own page objects, parent constructor should be called providing webdriver instance as a parameter


- Now supports both TestNg and JUnit frameworks - link
public ControlPeriodModel(WebDriver driver) {
super(driver);
WebDriverWait webDriverWait = new WebDriverWait(driver, 5000);
webDriverWait.until(ExpectedConditions.visibilityOf(getLblStatus().getElement()));
}
public ControlPeriodModel(WebDriver driver) {
super(driver);
this.getLblStatus().waitForElementToBeDisplayed(WAIT_EXPLICIT);
}
Now
Previously
Added more explicit waiting methods
Conclusion
ATSF Framework
- Tests are more concise and readable by using Decorator pattern for creating own classes for page elements.
- Handles asynchronous waiting for web elements out of the box
- Use only explicit waiting instead of implicit and thread.sleeps
- WebDriverFactory is handling driver instantiation/closing and maintaining the instance of browser and support for parallel execution
- Readable HTML reports by Allure (screenshots, logs; store attachments, steps, parameters, etc) and screenshot attachment support out of the box
- TestNg And JUnit support
Future
- PageFactory
- Better Selenium Grid management
- Custom Maven archetype for starting Selenium project from scratch with ATSF
- Support for Responsive Design testing
Thanks!
ATSF Components and Features
By Ilja Pavlovs
ATSF Components and Features
- 346