How to automate check for youtube video subtitle

Reading Time: 1 minute

TL;DR

In this post I will explain how I implemented check that youtube video contains specific language subtitle.

As part of application acceptance test, I needed to implement UI check that confirms that selected youtube video contains selected subtitle language. Getting the value of youtube video available subtitles from youtube player would be hard (even not manageable) task. So I decided to use different approach.

I remembered that while “search videos by subtitle language” feature was developed, developers mentioned (in github issue conversation) that this feature will be based on youtube api. So why not use this same code in my automated check?

The risk is here that we are using api that could return different list of available subtitles than one that are obtained using youtube UI elements. But knowing that Google is very good at testing their product features, I labeled that risk as very low.

youtube video subtitles
youtube video subtitles

Here is cucumber step definition:

It is important to state that I found on this blog post how to get attribute value using watir-webdriver.

Always use your tools wisely. Do not force one way of achieving something if there is more elegant way.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

How to automate heavy Javascript application?

Reading Time: 1 minute

TL;DR

Ember and Angular are examples of powerful web frameworks written in Javascript. Today, many modern websites are moving from traditional server side templates page generation and adapt those frameworks. How that affects browser automatization?

In asynchronous world, before any interaction with page element, it is good practice to wait for that element to become visible.

Here are watir webdriver waiting methods, and page object waiting methods. And in “heavy javascript application”, when I wait for element to become visible, I got exception

Watir::Exception::UnknownObjectException

The main issue here is that when you do some action, let’s say button click, javascript framework manipulates DOM tree. Your element was present in DOM tree before the action, but after the action was removed and you got UnknownObjectException.

Watir webdriver also has present wait methods, but that does not cover UnknownObjectException.

So, in order to tackle this problem, you need to write your UnknownObjectException handler, something like this:

Watir::Wait.until(load_timeout){
  begin     
    loading_layout_element.visible?
  rescue Watir::Exception::UnknownObjectException
    false
  end
}

 

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Headless browser testing in docker container

Reading Time: 2 minutes

TL;DR

In this post you will find out how to run headless chrome browser tests on your development machine using prepared and configured docker machine.

Docker enables you to run on your development machine minimal linux machine. You are in control which software will be installed in that linux machine. All linux machine configuration is stored in two files. Docker uses cache, so only changes in machine configuration are rerun.

Install Docker

First, you need to install Docker for your operating system. Fire up docker terminal after you installed it.

Type: docker-machine ls

Output:

Screen Shot 2016-02-14 at 11.11.42 AM

 

docker machine is linux (special docker flavour), that has docker software that will run your docker containers. It runs in virtualbox that is automatically installed with docker.

You can ssh to it:

 

Screen Shot 2016-02-14 at 11.19.15 AM

 

Clone this github repository that contains docker files needed for creating and running docker image. Follow the README instructions. And that it is, you can run headless chrome tests on your development machine. While those tests are running, you can use your development machine for other tasks.

Dockerfile

Here is official Dockerfile reference documentation. Dockerfile is source code for creating docker images. But I would like to save you time that I spent investigating the official documentation, so you will be ready to create your own docker images very quickly.

Important note: in order to be able to create your own docker images, previously you have successfully configured and installed linux, connected to linux machine, and you know your way around in linux shell.

You do not have to create Dockerfile from scratch. There is great Dockerfile repository, called Docker hub. In search box input what you need, e.g headless chrome, and there is high probability that somebody already have prepared what you are looking for.

If this is not the case, you can download Dockerfile and change it according to your needs. Check in Dockerfile reference what every docker command actually do.

docker-compose.yml

This is second file from docker ecosystem. It is a source code for creating docker containers and their interconnections based on docker machines. For example, WordPress site needs (according to good architecture practice) php container and mysql container.

Line 4 in docker-compose.yml maps current directory (your ui automation project folder) to web docker container app folder. That is the magic which enables docker to run your cucumber tests in docker linux container that is ready with headless chrome, something that is not possible on osx.

Volumes are important docker feature, because without them, docker container does not remember any changes.

Additional magic is that bundle install is run on docker-compose build only when Gemfile is changed.

For example:

  1. docker-compose run web bash
  2. cd ~
  3. touch text.txt
  4. exit
  5. docker-compose run web bash
  6. ls -al ~

There is no text.txt file!

Here is composer reference documentation.

Here are instructions how to start testing using headless chrome:

  1. in docker-composer.yml, replace {project_name} with name of your ui automation project folder name.
  2. copy Dockerfile, docker-entrypoint.sh and docker-composer.yml to your ui automation project folder.
  3. start docker terminal, cd to ui automation project folder.
  4. run docker-compose build –force-rm
  5. run your tests: docker-compose run web /bundle/bin/cucumber -f html -o chrome.html features/feature_name.feature

chrome.html file is created in your local folder, in root folder of ui automation repository!

 

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Testing CRUD functionality is not so easy

Reading Time: 2 minutes

TL;DR

In this post I will present challenges that tester should take into account when he needs to test CRUD functionality. Approach is black box testing and we will use only user UI interfaces.

Black box is testing approach where tester designs tests from his (research-based) knowledge of the product’s user characteristics and needs, the subject area being automated, the product’s market, risks and environment (hardware/software)[source].

CRUD acronym stands for Create, Retrieve, Update, Delete, set of features that usually come together in every application. How to test those features?

As a tester, you can not start to test CRUD functionality until Create feature is developed because other three features depend on it.

So you start with testing Create feature. But how you will be sure that this feature actually works? You can use user interface of Create feature. You will examine feature response messages. Like in happy path, “You successfully created object X!”. But is this enough? In order to check the Create feature, you can also use Retrieve feature. Retrieve feature would check is created data actually stored in the application and are all object data attributes accessible via Retrieve feature.

So, in order to be able to test Create feature, it is always handy to have working Retrieve feature. This is important information when you will be asked question: what do you need in order to be able to test Create feature?

In order to be able to check that Retrieve feature works, you need to be able to create test data. You need Create feature.

What about Update feature? First you need to Create data, then you can Update that data, but in order to be able to check that Update actually works, beside observing Update response messages, you will also use Retrieve feature (like in testing Create feature).

Delete feature needs Create and Retrieve features. With Create you create data, and with Read, you are checking that deleted object is actually deleted.

Conclusion

CRUD features are dependant on each other. And there is a risk that you are checking feature with other feature that might have issues.

Feature: Create

Helper feature: Retrieve

Test design: can I confirm that all created attributes are actually stored in the application?

Feature: Retrieve

Helper feature: Create

Test design: can I confirm that all created attributes are accessible via Retrieve feature?

Feature: Update

Helper features: Create, Retrieve

Test design: can I confirm that only updated attributes are updated? Can I confirm that not updated attributes are not changed?

Feature: Delete

Helper features: Create and Retrieve

Test design: can I confirm that deleted object is actually deleted from the application?

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather