Images SDKs - JavaScript

Using the Eyes SDK involves 4 main steps:

Create and config an Eyes object.

Start a test.

Add UI validation check points.

Close the test.

Let’s look at a short JavaScript example for creating a single test:

var https = require('https');
var Eyes = require('eyes.images').Eyes;
// This example uses RSVP library for creating promises.
var RSVP = require('rsvp');

// Switch between the versions to generate test failure.
var version = "0.1";
//var version = "0.2";

var eyes = new Eyes();
// This is your api key, make sure you use it in all your tests.
// Define the OS and hosting application to identify the baseline
eyes.setOs("Windows 7");
eyes.setHostingApp("My Maxthon browser");

// Start visual testing.
var testPromise ="Applitools site", "Sanity Test", {width: 785, height: 1087})
    .then(function () {
        // Load page image and validate.
        return getImage("","/download/contact_us.png/" + version).then(function (img) {
            // Visual validation point #1
            return eyes.checkImage(img, 'Contact-us page');
    .then(function () {
        // Load another page image and validate
        return getImage("", "/download/resources.png/" + version).then(function (img) {
            // Visual validation point #2
            return eyes.checkImage(img);
    .then(function () {
        // End visual testing. Validate visual correctness.
        return eyes.close(false);
    }, function () {
        return eyes.abortIfNotClosed();

// Handle test results.
testPromise.then(function (results) {
    console.log("results", results);

function getImage(host, path) {
    var options = {
        host: host,
        path: path

    var deferred = RSVP.defer();

    https.request(options, function (res) {
        res.setEncoding('binary'); // this

        var data = "";
        res.on('data', function(chunk) {
            return data += chunk;
        res.on('end', function() {
            return deferred.resolve(new Buffer(data, 'binary'));
        res.on('error', function(err) {
            console.log("Error during HTTP request");

    return deferred.promise;

Eyes Object

Eyes object is the main object in Applitools Eyes SDK.


var Eyes = require('eyes.protractor'); var eyes = new Eyes();


Before anything else, you should set the API key which allows you work with the Eyes server. Note that you use a static function for that, so it will be available to all of your objects. In order to obtain your API Key, login to Applitools Eyes web application and open your account details page.


Replace YOUR_API_KEY with the API key of your account (you can find it in your signup Email).



The open method returns a custom web driver object that monitors all the driver actions. From this point, the new custom driver object should be used for all the actions in the test.

For Ruby users, the initialization and the section for ending a test can be replaced with a call to eyes.test with the same parameters as which handles initialization and ending the test., app_name, test_name, viewport_size);

driver – the relevant Selenium Webdriver object.

appName – string that represents the logical name of the AUT (this name will be presented in the test result)

testName – string that represents the name of the test (this name will be presented in the test result

viewportSize – a predefined viewport size that will be used for the browser window during this test (this parameter is very important for visual tests to ensure that the test will run of a defined viewport size and the results will be consistent)

appWindow (only relevant for CodedUI) – the WinWindow or BrowserWindow object (when using BrowserWindow, a casting to WinWindow is required) of the application under test.



Visual validation checkpoint

The check window command will take a snapshot of the current window in the AUT and will perform smart visual comparison of that window with the baseline. In case this is a new window that does not exist in the baseline, this window will be added to the baseline.

eyes.checkImage(image, windowName, matchTimeout);

image - Buffer object represent in-memory image instance

windowName – string that represents the logical name of this window/validation point that will appear in the test result report.

matchTimeout - (optional) MatchTimeout in seconds, given for the step to pass.

Using OCR

The functionality is not yet available in this language and will be added in future versions of the SDK.


Ending a test

At the end of each test, make sure to call the eyes.close method to notify the service that the test completed successfully. It is recommended to also call the method eyes.abortIfNotClosed at the end of the test as part of the ‘finally’ block to distinguish between completed tests and tests which were aborted abnormally (e.g. an exception was thrown).

... eyes.close(); 
}finally { 

In the “finally” block of Selenium tests, you would usually also want to include “driver.quit()”, since the test has either finished or failed.



(Optional) Creating a batch of tests

The object BatchInfo represent a batch/collection of tests that will be unified as one group in the Test Manager screen and the result of all tests in a batch will determine the batch result. In order to start a batch, you should create a BatchInfo object, and associate it to the Eyes object (before calling the “”). In order to add additional tests to the same batch, make sure to call eyes.setBatch for each of the tests/Eyes objects (so every test in the batch should start with creating an Eyes object, calling eyes.setBatch, and ending the test with eyes.close).

eyes.setBatch(batchName, id, startDate);

batchName – string that represents the logical name that will be assigned to this batch.

Use the command eyes.setBatch to associate a test to the batch using the eyes instance

id - (nullable) Unique id to distinguish between the batches.

startDate - (nullable) Starting date string.


(Optional) Enabling Logs

The functionality is not yet available in this language and will be added in future versions of the SDK.


(Optional) Overriding test comparison level

Comparison sensitivity, aka ‘match level’ is set by default to Strict to get optimal coverage. Sometimes for specific tests it is required to change the default comparison level


Level - The match level of the test (For Ruby and Python use u

Exact - Pixel to pixel comparison, for demonstration purposes and debugging, will fail a test if a pixel is not in place. (not lace. (not recommended)

Strict - strict is the default match level, it mimics human eyes so only significant visual changes will be spotted, while small changes that are not visible to a human eye will be ignored.

Content - ignores style and anti-aliasing differences, while spotting content changes. (the content level can be useful if your website includes different styles which are not relevant for your tests).

Layout - ignores content changes, and detects only layout changes. (useful for pages with dynamic content and localized pages)

Note: Overriding the match level is only effective if set before initialization.


(Optional) Ending tests without throwing exception on failure

The default behavior on failure is to throw exception or raise error on test ending. To override this behavior use one of the overrides which takes boolean.

... eyes.close(false).then(function(testResults) { ... }); 
} finally { 

testResults - Test results details, Contains attributes about the test and the failure

such as: Steps - Total steps count Matches - Total matches count Mismatches - Total mismatches count Missing - How many missing steps found ExactMatches - Amount of matches compared in exact match level StrictMatches - Amount of matches compared in strict match level ContentMatches - Amount of matches compared in content match level LayoutMatches - Amount of matches compared in layour match level isNew - Boolean value indicates whether the test classified as a new test.


(Optional) Automatic baseline creation (Default: True)

New tests presented to the server are automatically saved as baseline. To override this functionality so baseline creation will be applied manually by reviewing and approving the steps in applitools eyes Test Manager, set ‘SaveNewTests’ to false before test stat.


*true/false - Either true or false.

(Optional) Auto-save on failure (Default: False)

For maintenance and debugging purposes it is possible to make eyes to save automatically failed results as baseline by setting ‘SaveFailedTests’ property to true before test started.

* It is highly unrecommended to set this property in production since all failures will be saved automatically without distinguishment between bugs and features.


*true/false - Either true or false

(Optional) Setting app environment attributes 

Normally applitools eyes SDKs automatically identifies the environment that is used to run the tests and creates a separate baseline for each environment. In order to override app environment parameters and ‘force’ Eyes to compare results of different environments, you can explicitly call ‘setAppEnvironment’:

hostOs - The OS name and its version or any other os-alike identifier. hostApp - The application name, if there is, such as browser name or any other app-alike identifier.

This functionality can be used to ‘force’ eyes to preset the hostOS and hostApplication so identical tests on different environments will be unified under the same baseline. Note that using this in such way will most likely cause the tests to fail, since in most cases there are some differences between how the AUT is presented in the different environments.