Comments (13)
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)
from chimpy.
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.
from chimpy.
@lucetius could you please take a look? Try to bump fibers and see if the tests are running
from chimpy.
as a temporary workaround i was able to proceed by overriding the versions in the npm-shrinkwrap.json
from chimpy.
i should note that [email protected] was present in many chimpy dependencies, not just in a single place...
from chimpy.
I am now also having this issue. Is there a plan to get this updated soon?
from chimpy.
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.
from chimpy.
@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?
from chimpy.
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.
from chimpy.
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.
from chimpy.
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..
from chimpy.
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 :/
from chimpy.
Hi, @schlaegerz , can you elaborate more on how to move forward with webdriverio v6?
from chimpy.
Related Issues (20)
- Node 10.1.0, Chimp and fibers problem (can we upgrade fibers?) HOT 33
- Hooks errors fix for #687 HOT 5
- Security vulnerability HOT 5
- Chrome render issue with chimp
- Make chimp work with JDK10 HOT 6
- Difference between this repo(Chimpy) and Chimp HOT 4
- wrapAsync is not defined HOT 2
- Problems running chimpy on Gitlab `Error: unknown error: Chrome failed to start: exited abnormally` HOT 6
- Chimpy doesn't appear to support Sauce Connect (which is required for testing non-public apps via Sauce Labs)
- Output still references to chimp and outdated website.
- Support latest version of Chrome! HOT 6
- I can't run the unit tests for Chimpy HOT 4
- Using import syntax in config file throws error
- Chimpy crashes upon app server restart with --ddp flag HOT 2
- chromedriver 2.46.0 download URL invalid
- Adding chimpy as dev-dependency breaks app HOT 2
- cannot install dev-dependencies -> jest-cli dependency is invalid
- Lots of warnings on deprecation of packages with Node 11.10.x itself HOT 2
- Project Abandoned, future of this project? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from chimpy.