I’m excited to share with you that I’ve added a new library to the Test Automation Essentials suite, that includes reusable code for Selenium based tests!
This is a Beta version because it still doesn’t include XML documentation and unit tests, which I try to include in the released versions. However, it is tested and is used in production in one of my customers!
To start using it, simply add it as a NuGet package as follows:
- Right click on the Project References
- Select “Manage NuGet Packages…”
- Make sure that “Online” is selected
- In the search box, type “TestAutomationEssentials.Selenium“. The package should appear in the search results
- Click “Install” to install the package.
So what’s in there?
UI is not always synchronous, and often elements are loaded in the background. Traditionally there were 3 ways to handle it:
- Use Thread.Sleep – clearly this is not a good choice because you must use the MAXIMAL possible duration, which wastes a lot of time for vain
- Use ImplicitWait – while this is a fine solution in most cases, it has the drawback of using the maximal wait duration in FindElements (the plural one), and often this is method is used to determine if an element exists or not, so it’s also wasteful. In addition, it’s not possible to get the current value of ImplicitWait in order to change it temporarily and reset it at the end in a safe way
- Use WebDriverWait – this is best approach in most cases, except that it’s pretty cumbersome to use everywhere.
The ElementsContainer.WaitForElement method in TestAutomationEssentials.Selenium gives a simple and clean API for waiting for elements. It takes a By object, a description and an optional timeout (with default of 30 seconds), and returns a BrowserElement object that wraps the found IWebElement. This method also waits for the element to be displayed. See the next paragraph for more details about the description argument and the BrowserElement class.
Automatic Logging of actions
Logging is an essential part of Test Automation. Without proper and clear logging it’s almost impossible to diagnose the root cause of failures.
However, filling the test code with with Logging messages is also hard to maintain, and makes the code itself harder to read.
In order to simplify that issue, the above mentioned ElementsContainer.WaitForElement returns a BrowserElement object, which is a wrapper around IWebElement, that automatically writes every action (click, set text, etc.) to the log. The log itself is the hierarchical logger managed by the TestAutomationEssentials.Common.Logger class that was already introduced in the existing TestAutomationEssentials.Common library.
In order to make the log more readable and less technical, each BrowserElement is assigned a description that you provide as an argument to the ElementsContainer.WaitForElement method.
Working with Frames and Windows made easy!
If you ever tried to write Selenium tests for an application which contain iframes and/or windows, you probably noticed that it whenever you use any of the SwitchTo() methods, the old elements that you previously found (on the original window or frame) are no longer available, and if you try to access them you get an StaleElementException.
TestAutomationEssentials.Selenium provides Browser, Frame and BrowserWindow classes as well as the BrowserElement class mentioned above. All of these classes derive from ElementsContainer which exposes the WaitForElement method (and few others).
The best thing about these classes is that you can use their objects as long as the corresponding Browser, Frame, Window or Element appear on the screen! No more SwitchTo().Frame() and SwitchTo().Window!
As this is a beta version, there’s a small chance that I’ll make some minor breaking changes in the released version, but not something you should worry about. Anyway, if you intend to use this library, I’d be happy if you let me know (email@example.com). This way I can also give you support as needed.
Lastly, you’re welcome to contribute by sending me Pull Requests!