A Test Automation Blog

As we all know, non-touch devices like a desktops have slightly different input from touch devices like mobile. This also means developers do have the option to build a website that does expect touch input instead of a mouse click. If your test suite does do a `element.click` when touch is expected, the click does not fail (at least not currently), so no error is thrown/shown but your script will fail. In one of my previous blog posts I mentioned a solution with execute_script and touchend . I did find out ( with the help of the watir community on Slack ), this can be resolved easier with Selenium and touch action (only supported on Chrome at the moment of writing). The specs In general spec documents are a bit difficult to interpret because of the lack of a clear example, but it gets easier to understand the structure over time. If you look at the specs of selenium-webdriver  you get an overview of all possibilities. There are a couple of points you could look if you think...

Intro  In one of my previous blog posts, I talked about a high level view of the whole test automation setup . It happens quiet often that people that begin with test automation forget to install the webdriver or are working with an older version of the webdriver. So in this post I wanted to go over this specific part and show some examples when testing local, with selenium-grid or via appium. What are webdrivers? In short I'd say: "Webdrivers are the bridge between your test automation framework and the browser. It can mimic user behavior on the browser so that your test script perform actions like a user would do".  How does it work?  The high level view of the flow is very straight forward. Your test scripts talk to Selenium, Selenium talks to the webdriver of your needs, the specific webdriver talks to the browser. So this means you need all components. The browser, the browser specific webdriver, selenium and a program language that is supported...

In the  "installation" blogpost , I mentioned that when you install lapis_lazuli, it also installs selenium-webdriver and watir. This blogpost I want to use to explain why I use the lapis_lazuli gem as well as a small comparison between the two to show you this added value. At the moment of writing I'm using lapis_lazuli 2.0.1, watir 6.10.0 and selenium-webdriver 3.7.0 Why I use the lapis_lazuli gem? First a little background info. This gem is developed and maintained by a QA company called spriteCloud (my former employer). This is how I got introduced to this gem. The gem was first introduced on Mar 30th, 2015 . I started to use it around november 2016. And on June 29th, 2017, they posted a blog with the title "Watir, Selenium and Cucumber on steroids" . This explains lapis_lazuli in a nutshell, give it a read. Now we have a basic understanding why lapis_lazuli was created, let's have a look at some of the differences and why I like the lapis_laz...

In the previous blogpos t  I explained the concepts of a test automation framework and which one I particularly like and want to share with you. In this blogpost we'll start to get our hands dirty by installing all necessary software so we can start with the fun. Keep in mind I'm writing this guide while working on a Windows computer, so it might be that you need to do some research for your OS if your following this guide while working on OSX or Linux. Browsers I'm not going to explain how to install a browser. But it's recommended to pre-install Firefox so it does not matter on what kind of OS you're working, you could still follow most of the instructions later on. And I'll start with the Firefox browser in the first test run. Other browsers will be covered later. So you can install them now or when we're getting there, that's up to you. Ruby Let's start with the installation of Ruby. My instructions will be similar if not identical ...