Artem Nagornyi's SDET recipes

There are many automated tests where you have to wait for certain fields to finish loading actual values on the web page before proceeding to the next verification point. You can see an example of such test below. At first, let’s implement a new method of the OrderPage class (we use a very simple page-object model here). This class also includes another method to open the page and element locators as getters. browser is a global WebdriverIO object that allows you to interact with the pre-initialized web browser of your choice. I used “wdio-chromedriver-service” to start Google Chrome, but you can use a different service. waitForMarketValuesToLoad method is waiting for the required fields to load the real values which are not the dashes (-). As you could probably guess, the dashes are loaded immediately upon opening the page and then the real values slowly start to appear, it can take several seconds to load values in those 4 fields. You can also add regular expressions to check t

Perhaps you are using Gitlab CI/CD at your project. Every project requires some test cases for regression testing, and Gitlab actually provides this feature, but it’s only available in Ultimate version that is more expensive. TestRail is another popular platform for managing your test suite that provides way more extensive capabilities and options than Gitlab’s own test case management feature. So the chances are that you are still willing to use TestRail for your acceptance and regression testing efforts. Why not combining the best of two worlds — the flexibility of Gitlab CI/CD and rich test case management capabilities of TestRail? In the following example I’ll demonstrate how this goal could be achieved with ease. Let’s assume that we need to create a new Milestone in TestRail that contains two test runs — the one with Acceptance tests, and another one with Regression tests. The step in your .gitlab-ci.yml Gitlab configuration file would look like this: This step is reading CI

There is a special feature in in Applitools Eyes that's called "coded ignore regions" to handle dynamic data. It's often used in Strict mode to increase test coverage if you don't want to switch to Layout mode. You can add coded ignore regions to the screenshot like this: target = target.ignore(By.id('reg1')).ignore(By.id('reg2')).ignore(By.id('reg3')); But what if these elements are created dynamically and you don't know how many of them will appear on the page? There could be 5 elements, or maybe 100... You cannot just add them in a chain by modifying a target like that. The answer is - you have to count them first and then add them in a loop. You can see the complete solution below for JavaScript.

When you use Applitools for testing, it is important to keep all pages in the same state as they used to be when the baseline Applitools screenshot was taken. In Applitools visual difference means a bug. This is why a blinking caret (cursor) can become a problem when the baseline screenshot was taken with a caret either visible or invisible, as long as the actual screenshot was captured with a different state of the caret. We can avoid this issue if we hide the caret by making it transparent before taking a screenshot in Applitools. This is how we can do it in Selenium Webdriver (Javascript bindings) (assuming that you initialized the driver object with Webdriver).

If you are already using SauceLabs for automated web UI testing on mobile devices, then you could be interested in trying TestObject cloud service that was acquired and became a part of SauceLabs family in 2017. It allows you to run your existing tests on real devices (Android and iPhone). SauceLabs provides emulators, which work quite well, but, depending on the requirements of your project, you may need to execute tests on real hardware. Another reason for switching to TestObject could be using the latest version of Android OS which may not be available at SauceLabs. At the moment of posting this article the latest supported version was Android 7.1 on SauceLabs and Android 8.1 on TestObject. Luckily the transition to TestObject is quite seamless. You don't need to modify your existing automated tests, only the provider endpoint and a few capabilities. The disanvantage of using a free Testobject account is that you are limited to only a few devices which are marked as Free in th

SauceLabs does not annotate jobs by default, showing the question marks instead of statuses, and the name of a job is always set to "Unnamed job". Luckily we have all the powers of Sauce Labs REST API in our hands and can both set the name of a job and its final status to something more meaningful. This example demonstrates how it can be done in Node JS. Every Sauce Labs job has a unique ID. We get this ID from the Webdriver object. saucelabs.js main.js

Assuming we have a CSV Data Source with multiple rows and 10 values in every row. We are parsing and storing the values into a set of variables, named var1,var2,var3,var4,var5,var6,var7,var8,var9,var10 . Now we can use these variables in any step using ${varN} reference. But what if we want to select a variable from this list randomly? So that one iteration would use var3 , and another iteration would use var7 , selected randomly. I have used the following solution: Create additional user defined variable varTmp using "User Defined Variables" config element. Create "Random Variable" config element with variable name rnd , minimum value 1 and maximum value 10. Then use BeanShell PostProcessor that will store the value from randomly selected variable (var1-var10) into varTmp . We need to define two fields in the config element:  Parameters:  ${__V(var${rnd})} Script: vars.put("varTmp", bsh.args[0]); Now we can use ${varTmp} as a reference to the

Synchronously waiting for a condition to be met in CasperJS (during AJAX calls and dynamic content loading on the page), implementation of helper methods: And now we can dynamically verify that our startup dialog has some text (in case the text is loaded by an AJAX call some time after the dialog was called):

Example of a Maven pom.xml file for execution of Jmeter tests that will automatically generate HTML reports and historical trends with pretty graphs with the help of a Chronos plugin. - Install Maven and make sure it works - Create some testmyapp.jmx Jmeter script and put it into ${basedir}/tests/ directory - Unpack the latest version of Jmeter into jmeter.home directory - And finally you execute the following commands ( -Dbuild.number parameter can be your build number and you can set it dynamically in your continuous integration system, this is just for convenience and even greater coolness of the script): Enjoy amazing HTML reports generated by Chronos!

Introducing a more robust way to click on the WebElement in situations when the native WebDriver click method doesn't work for some unknown yet obscure and annoying reason. Example of implementation in C# is given below. Probably porting of this code to Java wouldn't take too much time as well. Everything you need is a getter method with a CSS selector, which is automatically converted into Xpath in generateXpath method, and then the click event is triggered using JavaScript evaluate in ClickJS method. Works like a charm, also makes my tests more robust, especially in a multithreaded mode.

How to disable Save As dialog in Selenium WebDriver tests? Solution for Firefox (add more MIME media types if necessary): FirefoxProfile firefoxProfile = new FirefoxProfile(); firefoxProfile.setPreference("browser.download.folderList",2); firefoxProfile.setPreference("browser.download.manager.showWhenStarting",false); firefoxProfile.setPreference("browser.download.dir", "/save/file/to/this/directory"); firefoxProfile.setPreference("browser.helperApps.neverAsk.saveToDisk","text/html, application/xhtml+xml, application/xml, application/csv, text/plain, application/vnd.ms-excel, text/csv, text/comma-separated-values, application/octet-stream"); WebDriver driver = new FirefoxDriver(firefoxProfile); Solution for Google Chrome (this applies to all MIME media types): Map prefs = new Hashtable<>(); prefs.put("download.prompt_for_download", "false"); prefs.put("download.

Sometimes it's very helpful if we are able to click some element directly, by calling JavaScript click event. For example, this can be the case when the element is not visible, or not clickable, thus we cannot use native WebDriver methods. WebDriver driver = new FirefoxDriver(); JavascriptExecutor js = (JavascriptExecutor)driver; js.executeScript("document.querySelector('.pane .object_options .dropdown-toggle span').click();");

This small chunk of code will help you to take a screenshot of entire screen on any platform. It is especially helpful in test automation frameworks to add "take a screenshot on failure" functionality. captureScreen method accepts the filename of the image to be produced in PNG format including the full path (absolute or relative to the working directory), e.g. "out/screenshots/myscreen.png"

This is how we can execute a JavaScript function on a web page with Watir test automation framework .

It is more challenging to implement automated tests for websites using dynamic AJAX requests which load data or elements on the fly. With Watir test automation framework there are several different approaches. We can insert some fixed sleeps before the checkpoints. However this is a bad solution in many cases because quite often we don't know the exact time it takes, also fixed sleeps can make our tests very slow, especially when we have a large test automation suite. This is my solution for Watir test automation framework. It retries any operation with the element until success. If it fails for the first time, it retries again in 3 seconds, repeating 5 times until success. We can configure the maximum number of retries and the interval between each retry. Implementation of the method in Ruby Usage examples