Using require with relative paths
Asked Answered
M

5

54

We have a rather big set of end-to-end tests on Protractor. We are following the Page Object pattern which helps us to keep our tests clean and modular. We also have a set of helper functions which help us to follow the DRY principle.

The Problem:

A single spec may require multiple page objects and helper modules. For instance:

"use strict";

var helpers = require("./../../helpers/helpers.js");
var localStoragePage = require("./../../helpers/localStorage.js");
var sessionStoragePage = require("./../../helpers/sessionStorage.js");

var loginPage = require("./../../po/login.po.js");
var headerPage = require("./../../po/header.po.js");
var queuePage = require("./../../po/queue.po.js");

describe("Login functionality", function () {

    beforeEach(function () {
        browser.get("/#login");

        localStoragePage.clear();
    });

    // ...

});

You can see that we have that directory traversal in every require statement: ./../... This is because we have a specs directory where we keep the specs and multiple directories inside grouped by application functionality under test.

The Question:

What is the canonical way to approach the relative path problem in Protractor?

In other words, we'd like to avoid traversing the tree, going up to import modules. It would be much cleaner to go down from the base application directory instead.


Attempts and thoughts:

There is a great article about approaching this problem: Better local require() paths for Node.js, but I'm not sure which of the options is a recommended one when developing tests with Protractor.

We've also tried to use require.main to construct the path, but it points to the node_modules/protractor directory instead of our application directory.

Metternich answered 18/7, 2015 at 14:3 Comment(0)
G
28

I had the same problem and I ended up with the following solution. In my Protractor config file I have a variable which stores a path to a base folder of my e2e tests. Also, Protractor config provides the onPrepare callback, where you can use a variable called global to create global variables for your tests. You define them as a properties of that global variable and use the same way you use globals browser or element in tests. I've used it to create custom global require functions to load different types of entities:

// __dirname retuns a path of this particular config file
// assuming that protractor.conf.js is in the root of the project
var basePath = __dirname + '/test/e2e/';
// /path/to/project/test/e2e/

exports.config = {

    onPrepare: function () {

        // "relativePath" - path, relative to "basePath" variable

        // If your entity files have suffixes - you can also keep them here
        // not to mention them in test files every time

        global.requirePO = function (relativePath) {
            return require(basePath + 'po/' + relativePath + '.po.js');
        };

        global.requireHelper = function (relativePath) {
            return require(basePath + 'helpers/' + relativePath + '.js');
        };

    }

};

And then you can use these global utility methods in your test files right away:

"use strict";    

var localStorageHelper = requireHelper('localStorage');
// /path/to/project/test/e2e/helpers/localStorage.js 

var loginPage = requirePO('login');
// /path/to/project/test/e2e/po/login.po.js

var productShowPage = requirePO('product/show');
// /path/to/project/test/e2e/po/product/show.po.js


describe("Login functionality", function () {

    beforeEach(function () {
        browser.get("/#login");

        localStorageHelper.clear();
    });

    // ...

});
Grosberg answered 18/7, 2015 at 21:22 Comment(0)
J
19

We've been facing the same issue and decided to turn all page object and helper files into node packages. Requiring them in tests is now as easy as var Header = require('header-po'). Another benefit of converting to packages is that you can use proper versioning.

Here is a simple example:

./page-objects/header-po/index.js

//page-objects/header-po/index.js

'use strict';

var Header = function () {
    this.goHome = function () {
        $('#logo a').click();
    };
  };

module.exports = Header;

./page-objects/header-po/package.json

{
    "name": "header-po",
    "version": "0.1.1",
    "description": "Header page object",
    "main": "index.js",
    "dependencies": {}
}

./package.json

{
    "name": "e2e-test-framework",
    "version": "0.1.0",
    "description": "Test framework",
    "dependencies": {
        "jasmine": "^2.1.1",
        "header-po": "./page-objects/header-po/",
    }
}

./tests/header-test.js

'use strict';

var Header = require('header-po');

var header = new Header();

describe('Header Test', function () {
    it('clicking logo in header bar should open homepage', function () {
        browser.get(browser.baseUrl + '/testpage');
        header.goHome();
        expect(browser.getCurrentUrl()).toBe(browser.baseUrl);
    });
});
Jewett answered 25/7, 2015 at 8:17 Comment(0)
A
10

I have had the same issue. Did similar solution to Michael Radionov's, but not setting a global function, but setting a property to protractor itself.

protractor.conf.js

onPrepare: function() {
  protractor.basePath = __dirname;
}

test-e2e.js

require(protractor.basePath+'/helpers.js');

describe('test', function() {
   .......
});
Ackack answered 21/7, 2015 at 4:7 Comment(0)
T
2

I think the method we use where I work might be a good solution for you. I have posted a brief example of how we handle everything. It's pretty nice b/c you can just call the page object functions in any spec file and you don't need to use require in the spec.

Call a node module from another module without using require() everywhere

Taoism answered 24/7, 2015 at 20:56 Comment(0)
H
2

All answers seem to be more of workarounds

The actual working solution would be this:

    "_moduleAliases": {
        "@protractor": "protractor/_protractor",
        "@tmp": "protractor/.tmp_files",
        "@test_data": "protractor/.tmp_files/test_data",
        "@custom_implementation": "protractor/custom_implementation",
    },
  • add this as very first line of your protractor config
require('module-alias/register');
  • use it anywhere in the project like so
const params = require('@test_data/parameters');
const customImplementation require('@custom_implementation')
// etc
Harmonist answered 9/2, 2021 at 1:17 Comment(1)
I hope I didn't miss anything important, since I implemented this 2 years ago and still use it without modification. Let me knowHarmonist

© 2022 - 2024 — McMap. All rights reserved.