How to setup and run angular js protractor test in jenkins? - javascript

I have following configuration but getting error
ERROR
registration capabilities Capabilities [{platform=WINDOWS, ensureCleanSession=true, browserName=internet explorer, version=}] does not match the current platform LINUX
18:17:05.892 INFO - Driver provider org.openqa.selenium.edge.EdgeDriver registration is skipped:
registration capabilities Capabilities [{platform=WINDOWS, browserName=MicrosoftEdge, version=}] does not match the current platform LINUX
18:17:05.896 INFO - Driver class not found: com.opera.core.systems.OperaDriver
18:17:05.896 INFO - Driver provider com.opera.core.systems.OperaDriver is not registered
18:17:06.187 WARN - Failed to start: SocketListener0#0.0.0.0:4444
Exception in thread "main" java.net.BindException: Selenium is already running on port 4444. Or some other service is.
at org.openqa.selenium.server.SeleniumServer.start(SeleniumServer.java:492)
at org.openqa.selenium.server.SeleniumServer.boot(SeleniumServer.java:305)
at org.openqa.selenium.server.SeleniumServer.main(SeleniumServer.java:245)
at org.openqa.grid.selenium.GridLauncher.main(GridLauncher.java:64)
Selenium Standalone has exited with code 1
Selenium standalone server started at http://10.33.24.128:43448/wd/hub
Jenkins commands
## run testing
node_modules/protractor/bin/webdriver-manager update --standalone
node_modules/protractor/bin/webdriver-manager start > /dev/null 2>&1 &
while ! curl http://localhost:4444/wd/hub/status &>/dev/null; do :; done
node_modules/protractor/bin/protractor protractor.conf.js
My configuration file is below
exports.config = {
directConnect: false,
capabilities: {
'browserName': 'chrome'
},
chromeDriver: './node_modules/protractor/selenium/chromedriver',
seleniumAddress: 'http://localhost:4444/wd/hub',
framework: 'jasmine',
specs: ['tests/specs/*-spec.js'],
jasmineNodeOpts: {
showColors: true,
defaultTimeoutInterval: 30000
}
};

You have an error message:
Selenium is already running on port 4444. Or some other service is.
So your tests are failing because Selenium could not be set up, as the port it requires is already in use.
This could be perhaps because another build running in parallel on the same machine, or because Selenium wasn't stopped by a previous build, or some other server is using port 4444.
You need to ensure that this port is free before starting your build.
You can restrict multiple builds running in parallel on the same machine that want to use the same port number with the Port Allocator plugin or the Throttle Concurrent Builds plugin.

Avoid handling directly this and delegate it to gulp plugin like gulp-angular-protractor to:
1).Start/stop selenium server
2).And run protractor tests
Full Example
Gulpfile.js
/*jshint node: true, camelcase: false*/
/*global require: true*/
'use strict';
var gulp = require('gulp'),
gulpProtractorAngular = require('gulp-angular-protractor');
// Setting up the test task
gulp.task('regression-suite', function(callback) {
gulp
.src(['./tests/specs/*spec.js'])
.pipe(gulpProtractorAngular({
'configFile': 'protractor.conf.js',
'debug': false,
'autoStartStopServer': true
}))
.on('error', function(e) {
console.log(e);
})
.on('end', callback);
});
conf.js
Same as before
Command Prompt
C:>gulp regression-suite
Jenkins
Add a step as execute windows command
gulp regression-suite

Related

How to change selenium-standalone port number via webdriverio wdio file?

I need to change the port number of which selenium standalone server is using by default (4444). Port 4444 is currently in use, is there a way to alter the port number via the wdio file?
// 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: ['selenium-standalone'],
Currently I'm starting selenium server via the following command:
./node_modules/.bin/selenium-standalone start
I have also attempting to use the following with no luck:
./node_modules/.bin/selenium-standalone start -port 7777
Running the above command still attempt to run selenium sever on port 4444.
To run the selenium-standalone on the specific port you should use the following syntax:
./node_modules/.bin/selenium-standalone start -- -port 7777
Change the port in the wdi.conf.js:
seleniumArgs: {
seleniumArgs: ["-port", "7777"],
},
Also, read more about the wdio configuration file here and about wdio-cli here
So, your final wdio.conf.js should look like:
exports.config = {
/**
* server configurations
*/
services: ['selenium-standalone'],
port: 7777,
seleniumArgs: {
seleniumArgs: ["-port", "7777"],
},
}
nodejs webdriver-manager start --seleniumPort 5555

Chrome Driver Hangs intermittently while execution

I'm using protractor to automate my application, i have around 400 test cases to be automated, i use jenkins for Continous Integration.
Every day i trigger execution through Jenkins as part of nightly executions, but after some time Chrome Driver Hangs, i cant see the browser. But in console log in Jenkins i can see
"[launcher] 1 instance(s) of WebDriver still running" , i cant see browser and my execution can't proceed further and i had to forcefully stop the Build.
I'm using
Windows 7
Protractor 2.5.1
my sample conf.js file
framework: 'jasmine',
jasmineNodeOpts: {
onComplete: null,
defaultTimeoutInterval: 120000,
},
'autoStartStopServer': true,
capabilities: {
'browserName': 'chrome',
shardTestFiles: true,
maxInstances: 1
},
suites: {
specs: '../specs/module1/*.js',
},
I found similar issue with a proposed solution here and here it says to add DBUS_SESSION_BUS_ADDRESS=/dev/null but how to use the same in Windows, any help is appreciated.
In command promt (not git bash or cywin) try this command:
SET DBUS_SESSION_BUS_ADDRESS=/dev/null
To set Environment Variables then run node app, try this command:
SET DBUS_SESSION_BUS_ADDRESS=/dev/null&& node app.js

How to access chromedriver logs for Protractor test

I have seen that chromedriver can output a logfile (https://sites.google.com/a/chromium.org/chromedriver/logging)
This page shows how to set this up when executing the exe directly:
chromedriver.exe --verbose --log-path=chromedriver.log
I cannot figure out how to set this up in Protractor however
My current protractor.conf.js
require('babel/register');
exports.config = {
framework: 'jasmine2',
seleniumServerJar: './node_modules/protractor/selenium/selenium-server-standalone-2.45.0.jar'
};
From #alecxe's answer below and protractor's browser setup docs I tried adding the following (with and without --s) but with no apparent effect:
capabilities: {
browserName: "chrome",
chromeOptions: {
args: [
"--verbose",
"--log-path=chromedriver.log"
]
}
}
I also tried specifying an absolute path (log-path=/chromedriver.log) which also didn't work.
You can always start up your own instance of chromedriver in a separate process and tell Protractor to connect to that. For example, if you start chromedriver with:
chromedriver --port=9515 --verbose --log-path=chromedriver.log
Then you could use a configuration file for Protractor like so:
exports.config = {
seleniumAddress: 'http://localhost:9515',
capabilities: {
'browserName': 'chrome'
},
specs: ['example_spec.js'],
};
We use a shell script to add chromedriver logging, among other checks. You can then point protractor at the shell script:
protractor config:
// When running chromedriver, use this script:
chromeDriver: path.resolve(topdir, 'bin/protractor-chromedriver.sh'),
bin/protractor-chromedriver.sh
TMPDIR="/tmp"
NODE_MODULES="$(dirname $0)/../node_modules"
CHROMEDRIVER="${NODE_MODULES}/protractor/selenium/chromedriver"
LOG="${TMPDIR}/chromedriver.$$.log"
fatal() {
# Dump to stderr because that seems reasonable
echo >&2 "$0: ERROR: $*"
# Dump to a logfile because webdriver redirects stderr to /dev/null (?!)
echo >"${LOG}" "$0: ERROR: $*"
exit 11
}
[ ! -x "$CHROMEDRIVER" ] && fatal "Cannot find chromedriver: $CHROMEDRIVER"
exec "${CHROMEDRIVER}" --verbose --log-path="${LOG}" "$#"
According to the protractor's source code, chromedriver service is started without any arguments and there is no direct way to configure the arguments. Even though the chromedriver's Service Builder that protractor uses actually has an ability to specify the verbosity and the log path:
var service = new chrome.ServiceBuilder()
.loggingTo('/my/log/file.txt')
.enableVerboseLogging()
.build();
Old (incorrect) answer:
You need to set the chrome arguments:
capabilities: {
browserName: "chrome",
chromeOptions: {
args: [
"verbose",
"log-path=chromedriver.log"
]
}
},
See also:
Viewing outstanding requests
Since, the previous answer by #P.T. didn't work for me on Windows 7, I started with his suggestions and got it working on Windows. Here is a working solution for Windows 7 users.
STEP 1: Install BASH and JQ and confirm they are working on your Windows box
Download bash (for Windows 10
https://itsfoss.com/install-bash-on-windows/ ; for Windows 7
download latest here:
https://sourceforge.net/projects/win-bash/files/shell-complete/latest/ ; for Windows Server 2012 or any Windows OS that already has Git installed on it, you already have a bash.exe and sh.exe installed at C:\Program Files\Git\usr\bin or C:\Program Files (x86)\Git\usr\bin already
)
Install bash - For Windows 7/ download it and extract the zip files to a directory.
Download jq (https://stedolan.github.io/jq/) and install it in the same directory location as bash
Make SURE that you add your above directory (for Windows 7- where you extracted the bash zip files to; for other applicable OSes that have git, the path it is installed at) to your PATH system environment variable.
Once the above is installed and added to your PATH, close ALL and reopen Webstorm and any CMD windows you wish to run your work in.
Test that bash is actually installed by simply typing it on a windows command prompt
C:\git\> bash .
Doing so should produce a bash cmd prompt like this
bash$
STEP 2: Add Custom Files for Redirecting Chromedriver to user Debug Logging
Add the following files to the top level of the project (wherever your protractor-conf.js is located). These files allow us to add custom debug switches to the chromedriver.exe execution.
Note that this is necessary because these switches are not exposed through protractor and cannot be done directly in the protractor.conf.js file via the chromeOptions/args flags as you would normally expect
chromedriver.cmd -- exact source shown below:
bash protractor-chromedriver.sh %*
protractor-chromedriver.sh -- exact source shown below:
TMPDIR="$(dirname $0)/tmp"
NODE_MODULES="$(dirname $0)/node_modules"
SELENIUM="${NODE_MODULES}/protractor/node_modules/webdriver-manager/selenium"
UPDATECONFIG="${SELENIUM}/update-config.json"
EXEFILENAME="$(cat ${UPDATECONFIG} | jq .chrome.last | tr -d '""')"
CHROMEDRIVER="${SELENIUM}/${EXEFILENAME##*'\\'}"
LOG="${TMPDIR}/chromedriver.$$.log"
fatal() {
# Dump to stderr because that seems reasonable
echo >&2 "$0: ERROR: $*"
# Dump to a logfile because webdriver redirects stderr to /dev/null (?!)
echo >"${LOG}" "$0: ERROR: $*"
exit 11
}
[ ! -x "$CHROMEDRIVER" ] && fatal "Cannot find chromedriver: $CHROMEDRIVER"
exec "${CHROMEDRIVER}" --verbose --log-path="${LOG}" "$#"
/tmp -- create this directory at the top level of your project (same as the location of the protractor.conf.js file.
STEP 3: Update protractor.conf.js file.
In the protractor.conf.js file, add the following line as a property in the exports.config object. As in:
exports.config = {
.. ..
chromeDriver: 'chromedriver.cmd',
.. ..
STEP 4: Launch your tests
your test should now run and if the chrome driver outputs any log information it will appear in a file called chromedriver.???.log in the tmp directory under your project.
Important caveats
This script set up assumes you install and run protractor (and the chrome driver under it) within the local node_modules directory inside your project. That is how I run my code, because I want it complete self-contained and re-generated in the build process/cycle. If you have protractor/chromedriver installed globally you should change the CHROMEDRIVER variable within the protractor-chromedriver.sh file to match your installation of protractor/chrome driver.
hope that helps.
If you're using the seleniumServerJar, in protractor.conf.js set the logfile path to wherever you want it to write the file:
seleniumArgs: [
'-Dwebdriver.chrome.logfile=/home/myUsername/tmp/chromedriver.log',
]
If you're using webdriver-manager start to run a local selenium server, you'll need to edit the webdriver-manager file:
// insert this line
args.push('-Dwebdriver.chrome.logfile=/home/myUsername/tmp/chromedriver.log');
// this line already exists in webdriver-manager, add the push to args before this line
var seleniumProcess = spawnCommand('java', args);
In case you use webdriver-manager: webdriver manager has the chrome_logs option (you can find it in its source code (in opts.ts or opts.js in the compiled code)), so you can use it something like:
webdriver-manager start --chrome_logs /path/to/logfile.txt
I'm using this as a global afterEach hook (mocha):
afterEach(() => {
browser.manage().logs().get('browser').then(function(browserLog) {
if(browserLog && browserLog.length) {
console.log('\nlog: ' + util.inspect(browserLog) + '\n');
}
});
});

sails debug command not working in Sails.js

I am creating my first sails.js app. When I tried
sails debug
I'm getting the following error on my command prompt
Debugger listening on port 5858
info: Starting app...
error: Grunt :: Error: listen EADDRINUSE
at exports._errnoException (util.js:746:11)
at Agent.Server._listen2 (net.js:1129:14)
at listen (net.js:1155:10)
at Agent.Server.listen (net.js:1240:5)
at Object.start (_debugger_agent.js:20:9)
at startup (node.js:86:9)
at node.js:814:3
To get the PID of the process using port:5858, I tried running
C:\Windows\system32>netstat -a -n -o
but unfortunately there is no process bound to port 5858. Am I missing something here?
I'm using Windows 8.1 with node.js v0.12.0 and sails.js 0.11.0
My server uses node 0.10.38 with sails because of some weird unfixed grunt thing with 11+. Haven't pulled up this issue in a while, but it looks like there's new activity... check out this comment in particular, which explains the issue and a possible fix (direct quote):
Possible Solution:
Looking at the options for child_process.fork, the --debug flag is being passed down to the child upon exiting the womb i.e. running
sails debug :
// ./node_modules/sails/bin/sails-debug.js
// Spin up child process for Sails
Womb.spawn('node', ['--debug', pathToSails, 'lift'], {
stdio: 'inherit'
});
setting options.execArgv to an empty array removes the flag and allows the process to continue:
// ./node_modules/sails/lib/hooks/grunt/index.js
var child = ChildProcess.fork(
path.join(__dirname, 'grunt-wrapper.js'),
[
taskName,
'--pathToSails='+pathToSails,
'--gdsrc='+ pathToSails + '/node_modules'
],
{
silent: true,
stdio: 'pipe',
execArgv: []
}
);
It seems like a bug in Sails. You can apply the fix your self by replacing your Sails' file:
./node_modules/sails/lib/hooks/grunt/index.js
with the contents of the following:
https://raw.githubusercontent.com/balderdashy/sails/88ffc0ed9949f8c74ea390efb5610b0e378fa02c/lib/hooks/grunt/index.js
This is the file that will be in the Sails' release v12.
Did you try to run in debug like simple node.js?
node --debug app.js

Karma/Jasmine times out without running tests

I'm trying to run Karma/Jasmine from Grunt on a project generated with
http://newtriks.com/2013/12/31/automating-react-with-yeoman-and-grunt/
Karma launches PhantomJS (or Chrome) and, depending on singleRun, it either times out or just sits there and does nothing. I've tried changing captureTimeout and browserNoActivityTimeout based on reading solutions from people with similar problems, but it doesn't seem to work.
My relevant pacakge versions etc.:
NodeJS: 0.10.25
Karma: 0.12.16
Webpack: 1.1.11
webpack-dev-server: 1.4.1
karma-jasmine: 0.1.5
Linux: Ubuntu 14.04
I've found someone with the same problem on OS X:
I've tried updating all my dev dependencies to the latest versions but the problem still remains.
My console output is below. The webpack lines referring to bundle is now VALID/INVALID are worrying, but I can't find any info on what they mean. Here's my console output:
Running "karma:unit" (karma) task
DEBUG [config]: autoWatch set to false, because of singleRun
DEBUG [plugin]: Loading karma-* from /home/ed/workspace/wwb-app/node_modules
DEBUG [plugin]: Loading plugin /home/ed/workspace/wwb-app/node_modules/karma-chrome-launcher.
DEBUG [plugin]: Loading plugin /home/ed/workspace/wwb-app/node_modules/karma-coffee-preprocessor.
DEBUG [plugin]: Loading plugin /home/ed/workspace/wwb-app/node_modules/karma-firefox-launcher.
DEBUG [plugin]: Loading plugin /home/ed/workspace/wwb-app/node_modules/karma-html2js-preprocessor.
DEBUG [plugin]: Loading plugin /home/ed/workspace/wwb-app/node_modules/karma-jasmine.
DEBUG [plugin]: Loading plugin /home/ed/workspace/wwb-app/node_modules/karma-phantomjs-launcher.
DEBUG [plugin]: Loading plugin /home/ed/workspace/wwb-app/node_modules/karma-requirejs.
DEBUG [plugin]: Loading plugin /home/ed/workspace/wwb-app/node_modules/karma-script-launcher.
DEBG [plugin]: Loading plugin /home/ed/workspace/wwb-app/node_modules/karma-webpack-plugin.
INFO [karma]: Karma v0.12.16 server started at http://localhost:8080/
INFO [launcher]: Starting browser PhantomJS
DEBUG [temp-dir]: Creating temp dir at /tmp/karma-98204612
DEBUG [launcher]: /home/ed/workspace/wwb-app/node_modules/karma-phantomjs-launcher/node_modules/phantomjs/lib/phantom/bin/phantomjs /tmp/karma-98204612/capture.js
Hash: 89285186567c1bc5bb7f
Version: webpack 1.1.11
Time: 2ms
Asset Size Chunks Chunk Names
webpack: bundle is now VALID.
webpack: bundle is now INVALID.
DEBUG [web-server]: serving: /home/ed/workspace/wwb-app/node_modules/karma/static/client.html
DEBUG [web-server]: serving: /home/ed/workspace/wwb-app/node_modules/karma/static/karma.js
DEBUG [web-server]: upgrade /socket.io/1/websocket/CjC8pnQq5It2z_kWYB98
DEBUG [karma]: A browser has connected on socket CjC8pnQq5It2z_kWYB98
INFO [PhantomJS 1.9.7 (Linux)]: Connected on socket CjC8pnQq5It2z_kWYB98 with id 98204612
DEBUG [launcher]: PhantomJS (id 98204612) captured in 1.704 secs
WARN [PhantomJS 1.9.7 (Linux)]: Disconnected (1 times), because no message in 30000 ms.
DEBUG [karma]: Run complete, exitting.
DEBUG [launcher]: Disconnecting all browsers
DEBUG [launcher]: Process PhantomJS exited with code 0
DEBUG [temp-dir]: Cleaning temp dir /tmp/karma-98204612
Warning: Task "karma:unit" failed. Use --force to continue.
Aborted due to warnings.
Here's my karma.conf.js file:
'use strict';
module.exports = function (config) {
config.set({
basePath: '',
frameworks: ['jasmine'],
files: [
'test/helpers/**/*.js',
'test/spec/components/**/*.js'
],
preprocessors: {
'test/spec/components/**/*.js': ['webpack']
},
webpack: {
cache: true,
module: {
loaders: [{
test: /\.css$/,
loader: 'style!css'
}, {
test: /\.gif/,
loader: 'url-loader?limit=10000&minetype=image/gif'
}, {
test: /\.jpg/,
loader: 'url-loader?limit=10000&minetype=image/jpg'
}, {
test: /\.png/,
loader: 'url-loader?limit=10000&minetype=image/png'
}, {
test: /\.js$/,
loader: 'jsx-loader'
}]
}
},
webpackServer: {
stats: {
colors: true
}
},
exclude: [],
port: 8080,
logLevel: config.LOG_DEBUG,
colors: true,
autoWatch: true,
// Start these browsers, currently available:
// - Chrome
// - ChromeCanary
// - Firefox
// - Opera
// - Safari (only Mac)
// - PhantomJS
// - IE (only Windows)
browsers: ['PhantomJS'],
reporters: ['progress'],
captureTimeout: 60000,
browserNoActivityTimeout: 60000,
singleRun: true
});
};
I had the same problem. From a related GitHub Issue, I learned that you can extend the inactivity timeout.
Set this Karma config option in your gruntfile or karma config file:
browserNoActivityTimeout: 100000
I set it to 100 seconds and my tests ran successfully. I don't know what's causing the delay.
I've changed my Karma config, to
captureTimeout: 60000, // it was already there
browserDisconnectTimeout : 10000,
browserDisconnectTolerance : 1,
browserNoActivityTimeout : 60000,//by default 10000
Also I have 200-300 tests, PhantomJS 1.9.8
and it needs only about 100 mb memory for Phantom
With grunt and karma
They all together used about 300mb of memory.
We encountered a similar problem on our build servers.
Increasing the browserNoActivityTimeout worked to a point. We upped it to 60000ms, but the problem with phantomJS not disconnecting returned as the number of unit tests increasing.
We eventually tracked the problem down to the RAM available to phantomJS. We had 1100 unit tests that would take ~1m30s to run, but phantomJS would fail to disconnect within the 60000ms timeout.
The build node VM RAM was increased from 2GB to 4GB and the 1100 unit tests then took ~45s to run and phantomJS would disconnect with ~5s. A huge improvement.
There are two lessons:
1. PhantomJS is memory hungry, so make sure it has enough RAM to do its thing
2. Profile your code to learn where you can be more efficient with memory usage.
Another likely explanation is RequireJS getting in the way. I'm getting this exact error if I add 'requirejs' to the karma.conf.js in the config.frameworks array.
This seems to override the native require function and cause tests to not be executed. In my case the describe-block was triggered, but none if the it-blocks were.
In my case I hadn't included the following code in my test.js file:
requirejs.config({
callback: window.__karma__.start
});
describe('tests', function() {
...
Once this config was included the tests started running. Hopefully this saves someone else a lot of stress!
Remove the 'requires' from the karma config file, just use frameworks: ['jasmine'].
Check that localhost points correctly to 127.0.0.1 and not an unreachable IP, this can happen in dev environments using virtual machines for example.
This may not be the case for the OP here, but if the code you're testing hits an infinite loop, it will cause a disconnection on timeout just like this.
Here is why I was getting this error, might help someone in similar situation.
My main component had multiple child components which were using different services, one of the services had an HTTP call and the initialisation failed as I was using that service in ngInit() method of the child component.
To fix the issue, I had to import the above service in the main component specs and attach a mock for the service, it started working after that.
I solved this for my own environment. I had a bunch of nodejs packages installed globally. I didn't do a regression to figure out exactly what package caused the problem, but I strongly suspect that having karma installed globally was the cause.
If you have this problem then try
sudo npm -g remove karma
and if that doesn't work then I would remove all global node packages (except truly global packages like yeoman, grunt-cli, for example). And then install locally for your project.
I also noticed that when you run sudo npm -i on OS X, it changes the owner of ~/.npm to root and subsequent npm -i commands will fail with an EACCESS error,.
#Vijender's answer got me on the right track
It was as simple as replacing HttpClientModule in tests with HttpClientTestingModule.
beforeEach(async(() => {
TestBed.configureTestingModule({
imports: [
HttpClientTestingModule
]
}).compileComponents();
}));
I fixed this by removing a call to an async function at global scope, in my Root.tsx.
It was working in a 'real' browser window, but doesn't work in a test run.
It seems to make loading the module itself hang, so it doesn't even get as far as executing the async function (so log statements won't show up)
Edit:
This was caused by another async function, run at app startup, that was trying to do auth and redirect to another URL. That's why it worked in the browser but not in headless mode. Without any async test functions, the auth code never had a chance to jam the system. With an async test, the async auth code started running and caused the lock-up.
Moral of the story: if an async test is hanging, check what other async code is going on in the background.
afterEach(function () {
document.body.innerHTML = '';
});
Adding this fixed issue for me, tests started running much faster. Seems like it decreases load on headless browser.

Categories