Modular test scripts

Breaking it down

After you've written a few tests scripts, you don't really want all of them in one text file. I decided to break mine down into 4 layers:

  1. Routines generally useful for testing.
  2. Interacting directly with webdriver-sync
  3. Specific interactions with the AUT.
  4. High level scripts for individual features/bugs.

node.js already has a way of writing scripts in a modular way. You simply write the script to return a modules.export object, whose members become available to any other script that "requires" that file, e.g:

    //in Testing.js
module.exports = {

    assert: function testing_assert(cond, errmsg) {
        if (!cond) {
        return cond;

    files: {
        wipeFolder: function files_wipeFolder(path, matching) {
            matching = matching || /./;
            fs.readdirSync(path).forEach(function (fileName) {
                if (fileName.match(matching)) {
                    fs.unlinkSync(path + "/" + fileName);

    log: {
        //various log methods and properties
    //then in a higher level script file
    var testing = require("./Testing.js");

    testing.files.wipeFolder("/home/tester/downloads/", /\.csv$/);
    testing.assert($(".welcomeMessage").getText() === "Hello", 
        "Wrong welcome message");


Testing layer

As shown above, I've got routines for dealing with asserts, the local filesystem, logging (including marking the starting and ending of individual test cases) and starting and stopping timers.

webdriver-sync layer

We've seen a lot of this layer already in the previous page when discussing the selector syntax and even earlier when talking about instantiating browsers.

AUT layer

This is an attempt to abstract the business logic of the website away from its implementation. This is where I identified the locators discussed in the previous page. It also handles user admin, including logging in and out. There are also routines specific to the website's functionality, such as extracting values out of charts, filtering data as well as low-level server interactions such as tailing logs and dumping the database. The latter are implemented using the execSync npm module:

    var sh = require("execSync");

module.exports {
    //other business layer object members    
    ,host: ""
    ,ssh: function PTL_ssh(commands, user, stdout) {
        console.log("STARTING SSH SESSION");
        if (typeof user == "string") {
            user = user || "tester";
        } else {
            stdout = user;
            user = "tester";
        if (typeof commands == "string") {
            commands = [commands];
        //either execute something quietly
        if (!stdout) {
            return"ssh " + user + "@" + + " \"" 
                + commands.join("; ") + ";exit\"");
        //or return the stdout from the command
        return sh.exec("ssh " + user + "@" + + " \"" 
            + commands.join("; ") + ";exit\"").stdout;

    ,taillog: function PTL_tailllog(n) {
        n = n || 10;
        console.log("FETCHING LAST " + n + " LINES OF THE LOG");
        return sh.exec("ssh tester@" + + " \" tail -n " 
            + n + " /var/log/tomcat7/application.log\"").stdout;


High-level script layer

By the time we get to this layer, it shouldn't look much like a webdriver script (or javascript for that matter) but be a human-readable sequence of interactions and checks, e.g.

    //PTL is the AUT and "POR-748" is the related JIRA issue
    "POR-748": function() {
        log.startCase("Create a new organization");
        PTL.waitFor("ADMIN PAGE", "'Organization'").hover();
        $("'New'", 0).click();
        PTL.waitFor("NEW ORGANIZATION PAGE", "#name").set("Acme");

        log.startCase("Checking log for recent errors");
        var taillog = PTL.taillog(2);
            "Errors logged when creating a new organisation");

Big Testing Object

The tests are triggered as a node command line, so there is a file that contains a TESTS object which refers to each individual test script in the other files. It looks something like this:

//in ptl.js

var TESTS = {

    "Smoke": function (expectedBuildNumber, expectedArchiveNumber) {
        expectedBuildNumber = expectedBuildNumber || "";
        expectedArchiveNumber = expectedArchiveNumber || "";
        if (expectedBuildNumber && expectedArchiveNumber) {
            PTL.deploy(hgBranch, expectedArchiveNumber);

        if (!this.RequestAuthentication()) {
        log.startCase("Log in");
            "Wrong pre-permission landing page url " + PTL.url);
    ,"Other test": function () {
        //do stuff

    //..and other tests

    //then we read in the .js files that contain our other tests and add them to the TESTS object
    var testModules = ["admin", "SingleSite", "MultiSite", "Security", 
        "Actuals", "Config", "Charts", "InternetExplorer"];

    testModules.forEach(function (testModule) {
        var req = require("./" + testModule + ".js");
        for (var test in req) {
            TESTS[test] = req[test];

    //then some other stuff to check which development branch we're on 
    //and use the correct host, which I won't show here

The command to run the test will be something like:

    node ptl.js Chrome "POR-748"

So ptl.js is called with command line arguments and has to launch the named browser and run the specified test.

//in ptl.js
    var driverType = process.argv[2];
    var jenkinsJob = process.argv[3];//the reason for the name will be apparent later

    //here is where it gets tricky
    PTL = require("./Portal.js")(driverType);
    //PTL is now an object that contains the AUT layer (in this case the AUT is "Portal")
    //Creating PTL also instantiates the browser because

//in Portal.js - this is the AUT level
    //the module exports for Portal.js instantiates the browser, then returns the object
    var WDS = require("./WD.js");//the webdriver-sync layer

module.exports  = function (browserType) {
    var WD = WDS(browserType);

    return {

        locators: {


    //and finally the browser is instantiated in WD.js which in turn returns a function
    //which takes the driverType parameter passed along from the original command line
    //and then returns the object with the webdriver-sync layer members

//in WD.js

    var wd = require("webdriver-sync");
    var testing = require("./Testing.js");

    var FirefoxProfile = require(testing.HOME
        + "/node_modules/webdriver-sync/src/classes/FirefoxProfile.js");

module.exports = function (driverType) {
    var driver, caps;
    var profile = null;

    if (driverType == "Remote") {
        caps = new wd.DesiredCapabilities["internetExplorer"]();
        driver = new wd["RemoteWebDriver"]("", caps);
    } else {
        if (driverType == "IOS") {
            caps = new wd.DesiredCapabilities["ipad"]();
            driver = new wd["RemoteWebDriver"]("", caps);
        } else {
            if (driverType.match(/Firefox/i)) {
                //stop prompts for download locations
                profile = new FirefoxProfile();
                profile.setPreference("browser.helperApps.neverAsk.saveToDisk", "text/csv");
                driver = new wd["FirefoxDriver"](profile); 
            } else {
                if (driverType.match(/Chrome/i)) {
                    //to stop warning banner in Chrome 35+
                    var chromeOptions = new wd.ChromeOptions();
                    caps = new wd.DesiredCapabilities["chrome"]();
                    caps = new wd.DesiredCapabilities["chrome"]();
                    caps.setCapability("chromeOptions", chromeOptions);
                    driver = new wd["ChromeDriver"](caps);
                } else {
                    //internetExplorer probably
                    driver = new wd[driverType + "Driver"]();

    return {

        driver: driver,
        findElement: function WD_findElement(selector, index) {
            //...we've seen this before



The test-type argument we passed to Chrome above stops a security message appearing every time you run your tests and ruining any screenshots you might be taking. Peter Beverloo maintains a full list of Chrome command line options for the curious.

Similarly, the preference to automatically download csv files is added to the FirefoxProfile. There around 800 preferences available - you may not need any of them.

Running multiple tests

We don't want to run the command line for every single test, but we can easily call multiple tests in a single script file:

//in one of our test script files

module.exports = {
  //some individual tests named "POR-nnnn"
  ,"Single Site Tests": function () {
            "POR-976", "POR-1056", "POR-966",
            "POR-664", "POR-654", "POR-768", "POR-433","POR-657", 
            "POR-813", "POR-837", "POR-694", "POR-1081", "POR-1078"
        ].forEach(function (singleSiteTest) {
            console.log("RUNNING SINGLE SITE TEST: " + singleSiteTest);
        }, this);

Then the command line would be:

    node ptl.js Chrome "Single Site Tests"

So where is that $() method you promised?

That appears at the AUT level. Portal.js actually starts like this:

    var WDS         = require("./WD.js");
    var path        = require("path");
    var testing     = require("./Testing.js");
    var log         = testing.log;  
    var timer       = testing.timer;
    var fs          = require("fs");
    var sh          = require("execSync");
module.exports  = function (browserType) {
    var WD          = WDS(browserType);
    var browser     = WD.driver;
    var browserName = browser.getCapabilities().getBrowserName();

    //here we are:
    var $           = WD.findElement;
    //that was it
    var go          = WD.go;
    var getJSON     = WD.getJSON;
    var getHeaders  = WD.getHeaders;
    var browserLogs = WD.browserLogs;
    var waterfall   = WD.waterfall;

    return {
//specific locators
        locators: {
        //and so on
Next: Uploads and Downloads