javascript - relativas - ruta relativa js

Usar require con rutas relativas

Question

Tenemos un conjunto bastante grande de pruebas de extremo a extremo en el transportador. Seguimos el patrón de Objeto de página que nos ayuda a mantener nuestras pruebas limpias y modulares. También tenemos un conjunto de funciones auxiliares que nos ayudan a seguir el principio DRY .

El problema:

Una sola especificación puede requerir múltiples objetos de página y módulos auxiliares. Por ejemplo:

"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();
    });

    // ...

});

Puede ver que tenemos ese recorrido del directorio en cada instrucción ./../.. : ./../.. Esto se debe a que tenemos un directorio de specs donde mantenemos las especificaciones y múltiples directorios agrupados por la funcionalidad de la aplicación bajo prueba.

La pregunta:

¿Cuál es la forma canónica de abordar el problema de la ruta relativa en Protractor?

En otras palabras, nos gustaría evitar atravesar el árbol y subir a importar módulos. Sería mucho más limpio bajar del directorio de aplicaciones base en su lugar.

Intentos y pensamientos:

Hay un gran artículo sobre cómo abordar este problema: mejores rutas require () locales para Node.js , pero no estoy seguro de cuál de las opciones es la recomendada al desarrollar pruebas con Protractor.

También hemos tratado de usar require.main para construir la ruta, pero apunta al directorio node_modules/protractor lugar de nuestro directorio de aplicaciones.

Answer 1

Creo que el método que utilizamos donde trabajo podría ser una buena solución para usted. He publicado un breve ejemplo de cómo manejamos todo. Es bastante agradable b / c, simplemente puede llamar a las funciones de objeto de página en cualquier archivo de especificaciones y no necesita usar require en la especificación.

Llame a un módulo de nodo desde otro módulo sin usar require () en todas partes

Answer 2

He tenido el mismo problema. Hizo una solución similar a la de Michael Radionov, pero no estableció una función global, sino que estableció una propiedad para el transportador en sí.

protractor.conf.js

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

test-e2e.js

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

describe(''test'', function() {
   .......
});

Answer 3

Hemos estado enfrentando el mismo problema y decidimos convertir todos los objetos de página y archivos auxiliares en paquetes de nodos. Requerirlos en las pruebas ahora es tan fácil como var Header = require(''header-po'') . Otro beneficio de la conversión a paquetes es que puede usar versiones adecuadas.

Aquí hay un ejemplo simple:

./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);
    });
});

Answer 4

Tuve el mismo problema y terminé con la siguiente solución. En mi archivo de configuración de Protractor tengo una variable que almacena una ruta a una carpeta base de mis pruebas e2e. Además, la configuración de onPrepare proporciona la onPrepare llamada onPrepare , donde puede usar una variable llamada global para crear variables globales para sus pruebas. Las define como propiedades de esa variable global y las usa de la misma manera que usa el browser global o el element en las pruebas. Lo he usado para crear funciones de requisitos globales personalizados para cargar diferentes tipos de entidades:

// __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'');
        };

    }

};

Y luego puede usar estos métodos de utilidad global en sus archivos de prueba de inmediato:

"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();
    });

    // ...

});