Looking at our functional tests (FTs) we can highlight several problems:
- Synchronization code here like WaitFor is everywhere.
[When("opened Find Duplicate popup")]
public void OpenFindDuplicatePopup()
{
Context.SeleniumInstance.Click("//a[.='Find Duplicate']");
Synchronizer.WaitForAjax();
}
[When("wait for page to load")]
public void WaitForPageToLoad()
{
Context.SeleniumInstance.WaitForPageToLoad(Config.WaitForPageToLoad);
Synchronizer.WaitForAjax();
}
[When("clicked on Mark as Duplicate button")]
public void ClickMarkAsDuplicate()
{
Context.SeleniumInstance.Click("//button[.='Mark as Duplicate']");
Synchronizer.WaitForAjax();
}
- xpaths everywhere, and not many of them shared.
- We also depend on page structure while looking for web element heavily
- Dependency on TP database.
As our FTs depends on direct connection to database it prevents us to run them against any instance of TP and share tests with plugin developers from other companies.
- Contexts (AKA testing environment like 'create a project for a process, put user stories and assign a user then proceed') are not defined and not shared across all FTs
For now agreed on following decisions:
Synchronization code here like WaitFor is everywhere
&&
xpaths everywhere, and not many of them shared.
The solution is simple: heavily use
PageObject pattern.
The rule regarding xpath:
Don't use xpath.
We should rather use css selectors as they are much more stable to page structure changes. Css selectors used for testing should start with _ prefix
public IWebElement FirstNameInput
{
get { return _browser.FindElement(By.CssSelector("input._firstName")); }
}
Page Objects design rules:
- Page Object should be always created via DI container (structure map in our case). This will make our code more flexible in the matter of changes
The you can revise the following articles regarding best practices DI usage:
Poor-Man DI Antipattern Description
Dependency on TP database
Use REST to perform quick manipulation of Target Process site.
Contexts
Different tests may use the same contexts in the matter of system under test (SUT) test.
Some of tests may use slightly different contexts.
It is necessary to provide a possibility to reuse contexts or their parts across the FTs.
 |
Context Architecture
Whole Picture for new-style FTs
|
