Does it wrap around Selenium and provide a simpler or different method of invoking the functionality of Selenium?
I looked it up on Google and the best information I could find was this one https://www.ontestautomation.com/using-wrapper-methods-for-better-error-handling-in-selenium/.
This doesn't explicitly explain what a Selenium wrapper is but gives enough information to help understand what it is.
One of the definitions of a "wrapper" is:
In the context of software engineering, a wrapper is defined as an entity that encapsulates and hides the underlying complexity of another entity by means of well-defined interfaces.
So, any custom code you might use that implements Selenium code could be understood as a wrapper.
For example, Katalon Studio is a testing tool that uses Selenium under the hood i.e. Katalon's WebUI class methods are a wrapper around Selenium methods. The following two pieces of code are equivalent - they do the same thing:
WebElement element = driver.findElement(By.cssSelector("css-selector-of-the-element"));
element.click();
WebUI.click(testObject) //testObject defined elsewhere
This is just a simple example, but it shows how can you hide complexity behind simpler commands.
I know this question has already been answered but I can see it was never accepted as an answer. Now, the answer above explains exactly what a wrapper is : encapsulation. Which in itself means also that it hides the underlying complexity of another entity (Selenium classes in this case).
But let me elaborate and give you an actual example.
I've built a Framework around Selenium and made a nuget package out of it internal to my company. But this is one example on how to wrap Selenium By class. Using a delegate, you can simplify a lot of the calling methods :
private delegate void ValidationMethodDelegate(By locator, int timeout = ELEM_TIMEOUT);
//This method actions a delegate for regularly used methods with a By locator parameter,
//the value of the selector and the selector type which is a built-in framework enum
private void ActionMethod(ValidationMethodDelegate delegateMethod, string selectorValue, SelectorType selectorType)
{
if (!string.IsNullOrWhiteSpace(selectorValue))
{
switch (selectorType)
{
case SelectorType.Id:
delegateMethod(By.Id(selectorValue));
break;
case SelectorType.Xpath:
delegateMethod(By.XPath(selectorValue));
break;
case SelectorType.TagName:
delegateMethod(By.TagName(selectorValue));
break;
case SelectorType.CssSelector:
delegateMethod(By.CssSelector(selectorValue));
break;
case SelectorType.ClassName:
delegateMethod(By.ClassName(selectorValue));
break;
case SelectorType.LinkText:
delegateMethod(By.LinkText(selectorValue));
break;
case SelectorType.PartialLinkText:
delegateMethod(By.PartialLinkText(selectorValue));
break;
default:
break;
}
}
else
{
throw new AssertionException($"{this.GetType().Name}::{MethodBase.GetCurrentMethod().Name}():: Selector Value : '{selectorValue}' cannot be null or empty.");
}
}
//Example on how the delegate is used
public void Click(string selectorValue, SelectorType selectorType)
{
ActionMethod(PageHelper.Click, selectorValue, selectorType);
}
The PageHelper is a static class that implements internally to the framework most of Selenium's methods with assertions and waiting implementations. I have several layers of complexity in my framework. But you can make it simple too. The method click for me is wrapped also in another class that implements two methods one that finds the element by and the other than waits for an element to appear on screen. Both are other wrappers around Selenium methods and assertions.
If you are only doing tests for one application and won't have further use of Selenium then a framework is not a solution for you. Also wrappers would be kind of redundant outside your test solution.
I would say that wrappers would only be useful in the context where you are making multiple use for it (like the click or find element, etc.)
"Wrapper" is more like a software development design pattern, which developers use in the codebase when it is necessary.
You can read more in the book:
In scope of automated testing, there are other terms. I will explain for mobile automation.
Driver (Espresso, UIAutomator, Robotium, XCUITest) - receive commands from test and send them to app specialized interface in understandable way
You sent a command to press a button to the GUI driver - it accepts it via API and sends to the app (and we see a tap on the button in GUI).
Another app (which is over driver, let's call it superstructure in this context) that interacts with the app under test via one or more drivers (increasing usability or increasing possibilities) like Appium, Calabash.
Frameworks (JUnit, TestNG, Cucumber) - app that allows us to prepare, launch and gather all info regarding test executions
It will look like this:
Framework -> Our tests -> Superstructure -> Driver -> GUI in our application
