DEV Community: coffeestain.io

Emulate GeoLocation for Automated Testing with webdriverIO

Pablo Calvo — Fri, 01 May 2020 02:57:02 +0000

As exposed on the first post of this series, Google Chrome DevTools includes a series of features that facilitate the emulation of customers Experience Profiles, such as device, resolution and of course geographical location.

Chrome DevTools Protocol

Once you have mastered the art of manual testing and want to try some automated geoLocation testing, you don't have to look away looking for new tools. Chrome DevTools exposes its own Protocol which allow us to programmatically use the same tools you know how to use on the browser.

Let's automate it

For the sake of this post I decided to use webdriverIO to write the automated tests. The reason to use this framework is that there is 3rd party service already developed and ready to use that allow us to seamlessly use the devTools without adding any extra code.

Getting started

Setup the project

We need to create a folder, and start a nodeJs project. (Recommended: Make sure the latest version of node is installed).



$ mkdir webdriverio-test && cd webdriverio-test
$ npm init -y

Install webdriverIO CLI

Now let's install the wdio CLI, which provide us with tools to setup and run a basic webdriverIO project.



$ npm i --save-dev @wdio/cli

Generate a wdio config file and create a test folder

WebdriverIO uses a configuration file (by default wdio.conf.js) that contains the basic information of the framework. Once the basic setup is complete webdriverIO will look into ./test/specs for the test files.



$ npx wdio config -y
$ mkdir -p ./test/specs

Setup devTools service

So far we have only setup the basic default configuration for webdriverIO. On this next step we are going to include the devTools service which will provide us with capabilities to interact with the devTools protocol.



$ npm install @wdio/devtools-service --save-dev

Then go to the wdio.conf.js and add the devtools service to the webdriverIO configuration.



...
// Services take over a specific job you don't want to take care of. They enhance
// your test setup with almost no effort. Unlike plugins, they don't add new
// commands. Instead, they hook themselves up into the test process.
    services: ["devtools"],
..

This is basically all the necessary configuration

Now let's create some tests

Create a file under the folder above and name it geo.js. This file will contain our testing code.

Test Scenario

Navigate to https://www.where-am-i.net/ and verify the current position.
Use devTools to emulate a different location. (London)
Verify that the user is on a new location.
Again use devTools to emulate another location. (Tokyo)
Repeat the verification.

Read the comments in the code



const assert = require('assert')

describe('Check Location overriding the timezone', () => {
    it('Check the default timezone', () => {
        browser.url('https://www.where-am-i.net/')
        // this validation depends on where are you!
        // assert.equal(location.getText(), '19.075984, 72.877656')
        // you might get 0.0 and 0.0 the first time because of authorization issues
    })

    it('Check that London should be the timezone', () => {
        // change to london location and timezone
        // cdp is the command to use a devTools command
        // we are going to use the Emulation module
        // and the setGeoLocationOverride method
        // info: https://chromedevtools.github.io/devtools-protocol/tot/Emulation/
        // note: the location and timezone must match or you will get an unavailable position    

        browser.cdp('Emulation', 'setGeolocationOverride' , {
            latitude:51.507351,
            longitude:-0.127758,
            accuracy: 1
        })
        browser.cdp('Emulation', 'setTimezoneOverride', {
            timezoneId: 'Europe/London'
        })       
        browser.pause(3000) // wait so you can notice the map changing
        let location = $('#location') // get a location reference for validation
        assert.equal(location.getText(), '51.507351, -0.127758')

    })

    it('Check that Tokyo should be the timezone', () => {
        // change to lo Tokyo location and timezone
        browser.cdp('Emulation', 'setGeolocationOverride' , {
            latitude:35.689487,
            longitude:139.691706,
            accuracy: 1
        })

        browser.cdp('Emulation', 'setTimezoneOverride', {
            timezoneId: 'Asia/Tokyo'
        })
        browser.pause(3000) // wait so you can notice the map changing
        assert.equal($('#location').getText(), '35.689487, 139.691706')
    })
});

Let's execute the tests

Just run on your terminal



$ npx wdio wdio.conf.js

Just like that!! We just emulated different user locations with no need to add complicated code or any extra tooling.

Now what?

Well... this example is just a very small fragment of what you actually accomplish with devTools and webdriverIO. I encourage you to explore more the documentation for both tools and discover new capabilities that can be added to your tests.

webdriverIO devTools Service
Chrome devTools Protocol

Share your thoughts and comments on how you test geolocation within your automated tests!!

Emulate GeoLocation for Manual Testing

Pablo Calvo — Wed, 29 Apr 2020 15:54:46 +0000

In a web world so advanced that it is almost mandatory to deliver unique User Experiences to unique Customers Profiles, we need to make sure our system behaves as expected under different circumstances, and those circumstances can be as simple as where my customers are located.

Old fashion way!

One simple solution to test Geo Location features is to use a VPN provider that can easily transport us to almost anywhere in the world. But as simple as the solution looks like, it also comes with several constraints: Limited to the VPN provider location points and really hard to programmatically change location on demand, and of course the monetary cost of acquiring the service.

Google Chrome DevTools to the rescue!

With google chrome devTools we can easily override the user current geo location and test our unique experience. Check it out here.

Let's try it out!

Once you have followed the previous link and know how to change the default location, let's make some tests around it.

Navigate to https://www.where-am-i.net/, and check the current location.
Let's override the default user location to Berlin, and notice how the map is automatically updated.
Let's try one more time with a different city.

So far pretty awesome...

Custom locations

We can basically add anywhere in the world as a custom location, as long as the timezone matches with the geo coordinates.

Check this list to find the supported timezones.

First find a timezone you want to test. i.e. America/Costa_Rica.
Go to google maps and find the right coordinates. ..www.google.com/maps/place/San+Jos%C3%A9,+Costa+Rica/@**9.9314988,-84.0951252**,14.76z/data..
Then add everything as a new custom location on the Sensors window.

As simple as that you can know use your custom timezone.

Final Thoughts

Geo Location testing just turned very simple with Google Chrome and devTools. Of course you are limited to this specific browser and I think that the use of a VPN will be a solid complement for this kind of testing.

Comment below what you do to test geo location features on your website, and any comments you have!!

Playing around with selenium and openCV!

Pablo Calvo — Thu, 09 Jan 2020 18:30:39 +0000

Selenium library is frequently used for UI test automation, and was probably designed for it, but selenium itself is not a testing library and people quite often forget about it

Selenium is basically a set of tools that allow your code to interact with a browser and the html elements on it.

The selenium WebDriver architecture consists in four main parts:

The language bindings (libraries for each language).
The selenium server.
The browser drivers.
Finally, the drivers.

Playing around with selenium

Selenium is not a super fast processing tool, maybe because of the many components that need to get involved. I made a fun experiment to see how slow is really selenium by reducing the external dependencies at its minimum.

For the experiment I will basically be executing clicks against a system in which no internet call is executed on each click and also there is no html rendering happening (or this does not matter that much).

Python and open CV

I used python along with openCV to open an image and generate a list of pixel points for each black pixel on the given image.

def generate_coordenates():
    print('Generating coordinates based on image')
    image=cv2.imread('image2.png')
    black_coordinates = [] #initial position

    for i in range(image.shape[0]):
        for j in range(image.shape[1]):
            # find the black pixels
            if image[i,j,0]==0 and image[i,j,1]==0 and image[i,j,2]==0: 
                black_coordinates.append((j,i))

    print('Writing coordinates to file')
    # generate a coordinates file
    with open(COORDINATES_FILE, 'a') as out:
        for x, y in black_coordinates:
            out.write(f'{x},{y}\n')

    print('Finish generating coordinates file')

Selenium and a website like `MS Paint`

Then I use selenium to go to a website like MSPaint (https://kleki.com/) and generate an image based on the black pixels.

driver = webdriver.Chrome(DRIVER_LOCATION)
        with open(COORDINATES_FILE) as file:
            driver.get(DRAW_WEBSITE)
            driver.find_element_by_css_selector("html")

            # move to starting point
            actions = ActionChains(driver)
            actions.move_by_offset(STARTING_COORDINATES.get('x'), STARTING_COORDINATES.get('y'))
            # start painting
            for line in map(lambda line: line.rstrip('\n'), file):
                print('Creating move actions')
                xy = line.split(',') # split the x and y
                current = {'x': int(xy[0]), 'y': int(xy[1])} 
                move_to = {'x': current.get('x') - before.get('x'), 
                           'y': current.get('y') - before.get('y')}

                actions.move_by_offset(move_to.get('x'), move_to.get('y'))
                actions.click()
                before = current.copy()

            # finish painting
            actions.perform()

The process

A couple of minutes:

20 minutes:

50 minutes:

The results

The coordinates file ended up with 3777 rows. Because for each row selenium executes 2 actions: move_by_offset and click it means 7554 selenium actions were be executed.

The test took 54.67 minute to complete which means around 3280 seconds.

And if we do the math: 7554 / 3280 = ~2.30. It means that 2.30 selenium actions were executed per second.

Quite fun...

Comments?

cheers :) and remember to keep using selenium
https://pjcalvo.github.com

if you liked the post:

How slow is selenium?

Pablo Calvo — Wed, 08 Jan 2020 19:42:28 +0000

Revamp Selenium: Refine the way you use parent-child selectors

Pablo Calvo — Mon, 06 Jan 2020 16:27:58 +0000

Always keep in mind that automated tests should work for you... And should provide enough details on execution failures so all the involved parties spend less time analyzing failures, debugging and fixing problems!

The Statement

Imagine that we have the following DOM struct.

<ul class="post-list">
  <li>
    <a class="post-link" href="/testing/2019/12/18/broken-links-with-python.html">
      testing with python scrapy</a>
  </li>
  <li>
    <a class="post-link" href="/testing,/mocha,/javascript/2019/12/09/webdriverio-and-ddt.html">
      data driven testing in Mocha Js</a>
  </li>
</ul>

And lets say that for locating the first <a> element on the list you decide to use a simple css locator: .post-list .post-link or xpath: //ul[@class='post-list']//a[@class='post-link'].

when you run the following python script:

from selenium import webdriver
driver_location = './chromedriver'

driver = webdriver.Chrome(driver_location)
driver.get('https://pjcalvo.github.io')

parent_child_locator = '.post-list .post-link' #combined parent child locator
element = driver.find_element_by_css_selector(parent_child_locator)

print(f'Element was found with href: { element.get_attribute("href")}')
driver.close()

you get a console message like this:

Element was found with href: https://pjcalvo.github.io/testing/2019/12/18/broken-links-with-python.html

The problem

In case that one of the classes changed, and you re-run the script:

Message: no such element: Unable to locate element: {"method":"css selector","selector":".post-lists .post-links"}

Something happened!! but the message above is not really granular, we are using the class value of two different elements and so we can't figure out which class changed just by looking at the message. We will need to investigate, debug and tweak.

Solution

Let's change the approach on how we locate this element
first we are going to search the parent element, then execute a second search on the child element. Therefore we can easily and quickly understand what changes happened to our system.

from selenium import webdriver
driver_location = './chromedriver'

driver = webdriver.Chrome(driver_location)
driver.get('https://pjcalvo.github.io')

parent_locator = '.post-list' #only the parent
child_locator = '.post-links' #only the child

#search the parent then search the child
element = driver.find_element_by_css_selector(parent_locator) \
                .find_element_by_css_selector(child_locator) 

print(f'Element was found with href: { element.get_attribute("href")}')
driver.close()

in case of success the outcome is the same:

Element was found with href: https://pjcalvo.github.io/testing/2019/12/18/broken-links-with-python.html

but in case of failure:

Message: no such element: Unable to locate element: {"method":"css selector","selector":".post-links"}

Very fast we can identify that the problem is searching the child element, and the parent search is still working fine.

Final thoughts

This is a quite an easy example, but i feel that the point is also quite easy to understand. always be mindful about how you use css and xpath locators, you might be using them quite well, but as with any other system it is recommended to stop for a second, look at the code and re-factor in case of misuses.

There is something else to consider and give a thought. When you add more searches to the test you will also affect the performance of your execution; each search in this case is a new call to the selenium server. I am a fan of having tests working for me even when I have to write an extra line of code.

Comments?

cheers :) and remember to keep revamping your tests
https://pjcalvo.github.com

if you liked the post:

Data Driven Testing with MochaJs

Pablo Calvo — Tue, 31 Dec 2019 05:15:03 +0000

MochaJs and tests driven by input data ("data driven tests")

One thing I really like and 'dislike' about JavaScript is that there is not a single-better option of doing the same thing

What I mean is that the language provides you with enough flexibility to write the same functionality in many different ways, and deciding which is the best or worst way to implement it, will probably be very subjective.

I will explain below a very intuitive approach to use data driven with mochaJS in order to to cover a real life scenario

Pre-Requisites

For this article I will use nodeJS, so make sure that is installed.

Getting Started

First, lets create a folder project folder and create our package.json file

$ mkdir mocha-ddt && cd mocha-ddt
$ touch package.json

Now copy the following snippet in our recently created file. This is far from a real package.json file but works for the purpose

{
  "name": "mocha-sample",
  "scripts": {
    "test": "mocha"
  },
  "devDependencies": {
    "chai": "^4.2.0",
    "chai-http": "^4.3.0",
    "mocha": "^6.2.2"
  }
}

We just defined some dev dependencies and a script to run our tests. We are going to use chai for the assertions and http requests

Finally let's create a test folder under the root project, so we end up with the following path: mocha-ddt/test

Let's keep it simple

Firs't thing to understand is how mocha and chai work together. create a file called test.js under the test folder.

then we are going to add a simple test:

var chai = require('chai');  // assertions library
describe('When Math works', function() { // describe is our spec definition
  it('should return the result of a sum operation', function() { // this is our test case
    let sum = 2 + 2; // do I need to explain this?
    chai.expect(sum,'In case this fails this is the error').to.be.equal(4); // very simple validation
  });
});

Now we can run our test case, so under the root folder execute:

$ npm run test

And we can see the following output:

Let's get into a real life test scenario

Many times in my career I have being given with a list of links and a test case that says: For all this links, verify which ones work. So instead of writing different test cases, or even worse request them manually, we can use DDT to accomplish the task:

Create a new file mocha-ddt.js under the test folder and add the following:

// required libraries + chai-http as a chai plugin
var chai = require('chai'), 
  chaiHttp = require('chai-http'); // for this example we are going to use chai-http to perform http requests
chai.use(chaiHttp); 

// this is the magical data source. we are creating a json list of urls and a expected response code for each
let urls = [
    { 'url' : 'https://www.google.com', 'response_code' : 200},
    { 'url' : 'https://pjcalvo.github.io', 'response_code' : 200},
    { 'url' : 'https://dev.to/error500', 'response_code' : 500},
    { 'url' : 'https://pjcalvo.github.io/notfound/page', 'response_code' : 404}
]

describe('When the links are working as expected', function() {

  urls.forEach(({url, response_code }) => { // foreach is an iterator function that will run thought all the items on urls

    // using ` and $ {} we can simple format the test case name to a meaningful output
    it(`should return '${ response_code }' for request '${ url }'`, function(done) {  // done parameter is required by http-chai to handle the it when the operation is completed

      chai.request(url) // this url comes from urls.foreach element
        .get('/') // just on the 
        .end(function(err, res) {
           // here we will validate that the response call from http-chai will match the url response_code given above
          expect(res,`... instead got ${ res.status}`).to.have.status(response_code);
          done(); // you need this here to tell mocha that the request is completed
        });
    });
  });
});

Let's add a little explanation before running this sample: because javaScript is an interpreted language (which means that NodeJS reads every line at execution time and interpret it) we have a certain flexibility to create test cases during runtime. We could also create describes and add subsets of test cases based on if conditions, unlike Java in which the test cases need to be compiled in order for the test runner to find them. But we are not comparing apples with gallinas here.

So running again the test command npm run test, gives us a new very nice output.

Duty Segregation

An even cleaner solution would be separate the json data from the test file and add it to a urls.json and use a custom wrapper to read, transform and present it to the test files.

// data-wrapper.js
getUrl((condition) => {
  if (condition)
    return JSON.parse(fs.readFileSync('mocha-ddt/test/url.json'));
  else
    return JSON.parse(fs.readFileSync('mocha-ddt/test/thisotherjson.json'));

// test file
let testUrls = datawrapper.getUrl(condition);

This is more a suggestion, so we are not fully implementing it.

Final thoughts

As I said at the beginning there are many ways to accomplish the same outcome, I like this way of creating data driven tests because it is really easy to explain and with some teawking and condition it can also manage more complex scenarios. I have used this approach with UI testing using WDIO as the UI framework and it also adapts very well. just be mindful that UI tests are normally not stateless tests and to accomplish navigability you need to handle proper before and each scenarios.

Comments?

mocha
chaiJS
chai-http

Cheers :) and remember to be data driven
https://pjcalvo.github.com

DEV Community: coffeestain.io

Emulate GeoLocation for Automated Testing with webdriverIO

Chrome DevTools Protocol

Let's automate it

Getting started

Setup the project

Install webdriverIO CLI

Generate a wdio config file and create a test folder

Setup devTools service

Now let's create some tests

Let's execute the tests

Now what?

Emulate GeoLocation for Manual Testing

Old fashion way!

Google Chrome DevTools to the rescue!

Let's try it out!

Custom locations

Final Thoughts

Playing around with selenium and openCV!

Playing around with selenium

Python and open CV

Selenium and a website like MS Paint

The process

The results

How slow is selenium?

Revamp Selenium: Refine the way you use parent-child selectors

The Statement

The problem

Solution

Final thoughts

Data Driven Testing with MochaJs

MochaJs and tests driven by input data ("data driven tests")

Pre-Requisites

Getting Started

Let's keep it simple

Let's get into a real life test scenario

Duty Segregation

Final thoughts

Selenium and a website like `MS Paint`