node 12: bump fibers dependency

[hexsprite]

Trying Meteor 1.9 which includes node 12, requires fibers@4 for Node 12

[lgandecki]

@lucetius could you please take a look? Try to bump fibers and see if the tests are running

[hexsprite]

as a temporary workaround i was able to proceed by overriding the versions in the npm-shrinkwrap.json

[hexsprite]

i should note that fibers@3.0.1 was present in many chimpy dependencies, not just in a single place...

[schlaegerz]

I am now also having this issue. Is there a plan to get this updated soon?

[dweller23]

Alright so here's the problem: if we bump Fibers to 4, then Webdriver 4 seemingly becomes incompatible with Fibers, which means we would have to update to Webdriver 5, which is completely different thing, that would require major reimplementation of Chimpy. We might have to shelve this thing, unfortunately.

[hexsprite]

@dweller23 Dang! That sucks. What makes Webdriver 5 totally different? I looked at the announcement but it wasn't immediately clear. It seems like they reoganized the API a bit but it's still the same overall idea?

[lgandecki]

Right, the API is a bit different, and most probably we would have to use async/await instead of wrapping things with fiber? overall quite a bit of work if you want to keep existing tests. I don't imagine many people want to START a project with chimp nowadays anyway, so all we care (also for our internal purposes) is backward compatibility.
Looks like what we are going to do for our projects is to create a package inside a package, and that package should have only chimp-related things inside (chimp, chromedriver, etc). I guess there is no good reason to mix the dependencies of chimp and meteor anyway. And then we would start chimp with an older node. Things should be good for a while. Maybe we will find a better way going forward.

[schlaegerz]

I wonder if there is a way to strip this package down to just the parts that are relevant to integrating with the server and the cli and then let people handle the browser with whatever existing package they want.

I feel like it should be fairly straight forward to upgrade our existing tests to a new webdriver since there should be plenty of examples out there, but re-implementing all the other logic to get the ddp connection to the server for Meteor seems a bit more daunting since it is a bit more specific. That would be a very useful package to have access to, but I don't have nearly the understanding of this package to be able to strip out all the other stuff.

[hexsprite]

The ddp stuff is trivia. As a lazy Sunday challenge I decided to see if I could migrate to WebdriverIO 6 from my existing Chimp tests. Minor syntax changes (they even support sync mode so you don't need to use await if you don't want to). The major change being that browser.waitForExisting(etc) is now $(etc).waitForExisting() and so on.

DDP is as simple as:

const simpleDDP = require("simpleddp")
const ws = require("isomorphic-ws")

let opts = {
  endpoint: "ws://localhost:3000/websocket",
  SocketConstructor: ws,
  reconnectInterval: 5000
};
const server = new simpleDDP(opts);

Other than that pretty much all of my existing tests worked fine..

[schlaegerz]

Ok thanks for the tip on how to get this going! I am definitely looking to move on from chimp, but It’s hard to make the full jump. Meteor definitely needs some new docs on best testing practices since it still suggests chimp which won’t work going forward :/

[schlaegerz]

To help future people with this problem here is the code I ended up using. I put this in a file serverInstance

const simpleDDP = require("simpleddp")
const ws = require("isomorphic-ws")
var argv = require('minimist')(process.argv.slice(2));
let port = argv.socketPort || 3005

let opts = {
  endpoint: `ws://localhost:${port}/websocket`,
  SocketConstructor: ws,
  reconnectInterval: 5000
};
const server = new simpleDDP(opts);

server.execute = async function  (func) {
  var args = Array.prototype.slice.call(arguments, 1);
  var result;
  var timeout = parseInt(process.env['chimp.serverExecuteTimeout']) || 10000;
  setTimeout(function() {
    if (!result) {
      throw new Error('[chimp] server.execute timeout after ' + timeout + 'ms'); 
    }
  }, timeout);
  try {
    result = await server.call('xolvio/backdoor', func.toString(), args);
  } catch (exception) {
    if (exception.error === 404) {
      throw new Error('[chimp] You need to install xolvio:backdoor in your meteor app before you can use server.execute()');

    } else {
      throw exception;
    }
  }
  if (result.error) {
    console.error(result)
  var error = new Error('Error in server.execute: ' + result.error.mestsage);
    throw error;
  } else {
    return result.value;
  }
};
exports.server = server
module.exports = exports

and then called
const {server} = require('./serverInstance')

I switched to using webdriver directly which is a much better supported framework.

The biggest change I have to make is since my serveri.execute is now a promise I have to do await on all the calls and then if you are using webdriver you have to use their async api which I accomplished by making helper functions like this:

async click(selector, params){
    let elem = await $(selector)
    await elem.click(params)
 }

Then you can just all
await click('.my-classname')

Hopefully this helps other people who are stuck with chimp and want to move on. I don't have to really functionally change my tests much, just have to change the syntax of all the calls.

[xywang68]

Hi, @schlaegerz , can you elaborate more on how to move forward with webdriverio v6?

[schlaegerz]

So i got rid of chimpy completely since it was no longer doing me any good

i directly install webdriver through npm, I have these packages
"@wdio/cli": "^6.1.15",
"@wdio/local-runner": "^6.1.14",
"@wdio/mocha-framework": "^6.1.14",
"@wdio/spec-reporter": "^6.1.14",
"chromedriver": "^83.0.0",
"wdio-chromedriver-service": "^6.0.3",

I ended up making a wdio.conf.js file:

// @noflow
let args =  process.env.HEADLESS ? ['--headless', '--disable-gpu'] :[]
let grep =  process.env.HEADLESS ? '^((?!@circleciignore).)*$' : ''
exports.config = {
    //
    // ====================
    // Runner Configuration
    // ====================
    //
    // WebdriverIO allows it to run your tests in arbitrary locations (e.g. locally or
    // on a remote machine).
    runner: 'local',
    //
    // Override default path ('/wd/hub') for chromedriver service.
    path: '/',
    port:9515,
    socketPort: 3005,
    //
    // ==================
    // Specify Test Files
    // ==================
    // Define which test specs should run. The pattern is relative to the directory
    // from which `wdio` was called. Notice that, if you are calling `wdio` from an
    // NPM script (see https://docs.npmjs.com/cli/run-script) then the current working
    // directory is where your package.json resides, so `wdio` will be called from there.
    //
    specs: [
        './tests/e2e/*.js'
    ],
    // Patterns to exclude.
    exclude: [
        // 'path/to/excluded/files'
    ],
    //
    // ============
    // Capabilities
    // ============
    // Define your capabilities here. WebdriverIO can run multiple capabilities at the same
    // time. Depending on the number of capabilities, WebdriverIO launches several test
    // sessions. Within your capabilities you can overwrite the spec and exclude options in
    // order to group specific specs to a specific capability.
    //
    // First, you can define how many instances should be started at the same time. Let's
    // say you have 3 different capabilities (Chrome, Firefox, and Safari) and you have
    // set maxInstances to 1; wdio will spawn 3 processes. Therefore, if you have 10 spec
    // files and you set maxInstances to 10, all spec files will get tested at the same time
    // and 30 processes will get spawned. The property handles how many capabilities
    // from the same test should run tests.
    //
    maxInstances: 1,
   
    //
    // If you have trouble getting all important capabilities together, check out the
    // Sauce Labs platform configurator - a great tool to configure your capabilities:
    // https://docs.saucelabs.com/reference/platforms-configurator
    //
    capabilities: [{
    
        // maxInstances can get overwritten per capability. So if you have an in-house Selenium
        // grid with only 5 firefox instances available you can make sure that not more than
        // 5 instances get started at a time.
        maxInstances: 1,
        //
        browserName: 'chrome',
        // If outputDir is provided WebdriverIO can capture driver session logs
        // it is possible to configure which logTypes to include/exclude.
         excludeDriverLogs: ['*'], // pass '*' to exclude all driver session logs
         'goog:chromeOptions': {
            // to run chrome headless the following flags are required
            // (see https://developers.google.com/web/updates/2017/04/headless-chrome)

             args: args
        },
    }],
    //
    // ===================
    // Test Configurations
    // ===================
    // Define all options that are relevant for the WebdriverIO instance here
    //
    // Level of logging verbosity: trace | debug | info | warn | error | silent
    logLevel: 'error',
    //
    // Set specific log levels per logger
    // loggers:
    // - webdriver, webdriverio
    // - @wdio/applitools-service, @wdio/browserstack-service, @wdio/devtools-service, @wdio/sauce-service
    // - @wdio/mocha-framework, @wdio/jasmine-framework
    // - @wdio/local-runner, @wdio/lambda-runner
    // - @wdio/sumologic-reporter
    // - @wdio/cli, @wdio/config, @wdio/sync, @wdio/utils
    // Level of logging verbosity: trace | debug | info | warn | error | silent
    // logLevels: {
    //     webdriver: 'info',
    //     '@wdio/applitools-service': 'info'
    // },
    //
    // If you only want to run your tests until a specific amount of tests have failed use
    // bail (default is 0 - don't bail, run all tests).
    bail: 1,
    //
    // Set a base URL in order to shorten url command calls. If your `url` parameter starts
    // with `/`, the base url gets prepended, not including the path portion of your baseUrl.
    // If your `url` parameter starts without a scheme or `/` (like `some/path`), the base url
    // gets prepended directly.
    baseUrl: 'http://localhost:3005',
    //
    // Default timeout for all waitFor* commands.
    waitforTimeout: 5000,
    //
    // Default timeout in milliseconds for request
    // if browser driver or grid doesn't send response
    connectionRetryTimeout: 90000,
    //
    // Default request retries count
    connectionRetryCount: 10,
    //
    // Test runner services
    // Services take over a specific job you don't want to take care of. They enhance
    // your test setup with almost no effort. Unlike plugins, they don't add new
    // commands. Instead, they hook themselves up into the test process.
    services: ['chromedriver'],
    
    // Framework you want to run your specs with.
    // The following are supported: Mocha, Jasmine, and Cucumber
    // see also: https://webdriver.io/docs/frameworks.html
    //
    // Make sure you have the wdio adapter package for the specific framework installed
    // before running any tests.
    framework: 'mocha',
    //
    // The number of times to retry the entire specfile when it fails as a whole
     specFileRetries: 2,
    //
    // Test reporter for stdout.
    // The only one supported by default is 'dot'
    // see also: https://webdriver.io/docs/dot-reporter.html
    reporters: [ 'spec'],
 
    //
    
    // Options to be passed to Mocha.
    // See the full list at http://mochajs.org/
    filesToWatch: ['./tests/**/*.js', './wdio.conf.js', './package.json', '**/*.test.js'],
    mochaOpts: {
        ui: 'bdd',
        timeout: 60000,
        compilers: ['js:@babel/register'],
        grep: grep,
        watch:'./tests/**/*.js',
        bail:1,
    },
    //
    // =====
    // Hooks
    // =====
    // WebdriverIO provides several hooks you can use to interfere with the test process in order to enhance
    // it and to build services around it. You can either apply a single function or an array of
    // methods to it. If one of them returns with a promise, WebdriverIO will wait until that promise got
    // resolved to continue.
    /**
     * Gets executed once before all workers get launched.
     * @param {Object} config wdio configuration object
     * @param {Array.<Object>} capabilities list of capabilities details
     */
    // onPrepare: function (config, capabilities) {
    // },
    /**
     * Gets executed just before initialising the webdriver session and test framework. It allows you
     * to manipulate configurations depending on the capability or spec.
     * @param {Object} config wdio configuration object
     * @param {Array.<Object>} capabilities list of capabilities details
     * @param {Array.<String>} specs List of spec file paths that are to be run
     */
     //beforeSession: function (config, capabilities, specs) {
     //},
    /**
     * Gets executed before test execution begins. At this point you can access to all global
     * variables like `browser`. It is the perfect place to define custom commands.
     * @param {Array.<Object>} capabilities list of capabilities details
     * @param {Array.<String>} specs List of spec file paths that are to be run
     */
    // before: function (capabilities, specs) {
    // },
    /**
     * Runs before a WebdriverIO command gets executed.
     * @param {String} commandName hook command name
     * @param {Array} args arguments that command would receive
     */
    // beforeCommand: function (commandName, args) {
    // },
    /**
     * Hook that gets executed before the suite starts
     * @param {Object} suite suite details
     */
     beforeSuite: function (suite) {
        console.info("Running", suite.title)
     },
    /**
     * Function to be executed before a test (in Mocha/Jasmine) starts.
     */
     beforeTest: function (test) {
        console.info("Running", test.title)
    },
    /**
     * Hook that gets executed _before_ a hook within the suite starts (e.g. runs before calling
     * beforeEach in Mocha)
     */
    // beforeHook: function (test, context) {
    // },
    /**
     * Hook that gets executed _after_ a hook within the suite starts (e.g. runs after calling
     * afterEach in Mocha)
     */
    // afterHook: function (test, context, { error, result, duration, passed, retries }) {
    // },
    /**
     * Function to be executed after a test (in Mocha/Jasmine).
     */
     afterTest: function(test, context, { error, result, duration, passed, retries }) {
        console.info("Finished", test.title, "Time (ms)", duration, passed, retries, error, result)

     },


    /**
     * Hook that gets executed after the suite has ended
     * @param {Object} suite suite details
     */
    // afterSuite: function (suite) {
    // },
    /**
     * Runs after a WebdriverIO command gets executed
     * @param {String} commandName hook command name
     * @param {Array} args arguments that command would receive
     * @param {Number} result 0 - command success, 1 - command error
     * @param {Object} error error object if any
     */
    // afterCommand: function (commandName, args, result, error) {
    // },
    /**
     * Gets executed after all tests are done. You still have access to all global variables from
     * the test.
     * @param {Number} result 0 - test pass, 1 - test fail
     * @param {Array.<Object>} capabilities list of capabilities details
     * @param {Array.<String>} specs List of spec file paths that ran
     */
    // after: function (result, capabilities, specs) {
    // },
    /**
     * Gets executed right after terminating the webdriver session.
     * @param {Object} config wdio configuration object
     * @param {Array.<Object>} capabilities list of capabilities details
     * @param {Array.<String>} specs List of spec file paths that ran
     */
    // afterSession: function (config, capabilities, specs) {
    // },
    /**
     * Gets executed after all workers got shut down and the process is about to exit. An error
     * thrown in the onComplete hook will result in the test run failing.
     * @param {Object} exitCode 0 - success, 1 - fail
     * @param {Object} config wdio configuration object
     * @param {Array.<Object>} capabilities list of capabilities details
     * @param {<Object>} results object containing test results
     */
    // onComplete: function(exitCode, config, capabilities, results) {
    // },
    /**
    * Gets executed when a refresh happens.
    * @param {String} oldSessionId session ID of the old session
    * @param {String} newSessionId session ID of the new session
    */
    //onReload: function(oldSessionId, newSessionId) {
    //}
}

and now I run my tests directly with webdriver

./node_modules/.bin/wdio wdio.conf.js --socketPort 3005 --bail

Note:
I still do use xolvio:cleaner and xolvio:backdoor meteor packages as they are still useful for the tests
and i still have meteortesting:mocha install (not sure if that is necesary or not atm)