How to link feature files with step definition in CodeceptJS? - phpstorm

I'm trying to implement the BDD framework in CodeceptJS using PHPStorm as my IDE. But for some reason it is not recognising the step definitions and in the feature file it shows the error
Undefined step reference
I followed the steps given in the CodeceptJS documentation such as codeceptjs gherkin:init (which implemented the gherkins module) and codeceptjs gherkin:snippets (which implements the step definition automatically)
I'm running on
MacOS
CodeceptJS on PHPStorm
Selenium Server with ChromeDriver
My codecept.conf.js file
exports.config = {
output: './output',
helpers: {
WebDriver: {
smartWait: 10000,
url: 'my_url',
browser: 'chrome'
}
},
include: {
I: './steps_file.js',
assignmentsPage: './pages/AssignmentsPageObject.js'
},
mocha: {},
bootstrap: null,
teardown: null,
hooks: [],
gherkin: {
features: './features/*.feature',
steps: ['./step_definitions/steps.js']
},
plugins: {
screenshotOnFail: {
enabled: true
}
},
tests: './*_test.js',
name: 'AssignmentsClient'
}
I expect the framework to detect the step defintion corresponding to the various scenarios mentioned in the feature file.
Can someone help me here?

CodeceptJS is not currently supported, please vote for WEB-31128 to be notified on any progress with this feature

Update: The reason why the BDD framework wasn't being recognised is because PHPStorm doesn't support a cucumber plugin. So it shows undefined only in the IDE. Once you start running the tests from the terminal, it gets recognised and works accordingly.

Related

Install multiple vs code extensions in CICD

My unit test launch looks like this. As you can see I have exploited CLI options to install a VSIX my CICD has already produced, and then also tried to install ms-vscode-remote.remote-ssh because I want to re-run the tests on a remote workspace.
import * as path from 'path';
import * as fs from 'fs';
import { runTests } from '#vscode/test-electron';
async function main() {
try {
// The folder containing the Extension Manifest package.json
// Passed to `--extensionDevelopmentPath`
const extensionDevelopmentPath = path.resolve(__dirname, '../../');
// The path to the extension test runner script
// Passed to --extensionTestsPath
const extensionTestsPath = path.resolve(__dirname, './suite/index');
const vsixName = fs.readdirSync(extensionDevelopmentPath)
.filter(p => path.extname(p) === ".vsix")
.sort((a, b) => a < b ? 1 : a > b ? -1 : 0)[0];
const launchArgsLocal = [
path.resolve(__dirname, '../../src/test/test-docs'),
"--install-extension",
vsixName,
"--install-extension",
"ms-vscode-remote.remote-ssh"
];
const SSH_HOST = process.argv[2];
const SSH_WORKSPACE = process.argv[3];
const launchArgsRemote = [
"--folder-uri",
`vscode-remote://ssh-remote+testuser#${SSH_HOST}${SSH_WORKSPACE}`
];
// Download VS Code, unzip it and run the integration test
await runTests({ extensionDevelopmentPath, extensionTestsPath, launchArgs: launchArgsLocal });
await runTests({ extensionDevelopmentPath, extensionTestsPath, launchArgs: launchArgsRemote });
} catch (err) {
console.error(err);
console.error('Failed to run tests');
process.exit(1);
}
}
main();
runTests downloads and installs VS Code, and passes through the parameters I supply. For the local file system all the tests pass, so the extension from the VSIX is definitely installed.
But ms-vscode-remote.remote-ssh doesn't seem to be installed - I get this error:
Cannot get canonical URI because no extension is installed to resolve ssh-remote
and then the tests fail because there's no open workspace.
This may be related to the fact that CLI installation of multiple extensions repeats the --install-extension switch. I suspect the switch name is used as a hash key.
What to do? Well, I'm not committed to any particular course of action, just platform independence. If I knew how to do a platform independent headless CLI installation of VS Code:latest in a GitHub Action, that would certainly do the trick. I could then directly use the CLI to install the extensions before the tests, and pass the installation path. Which would also require a unified way to get the path for vs code.
Update 2022-07-20
Having figured out how to do a platform independent headless CLI installation of VS Code:latest in a GitHub Action followed by installation of the required extensions I face new problems.
The test framework options include a path to an existing installation of VS Code. According to the interface documentation, supplying this should cause the test to use the existing installation instead of installing VS Code; this is why I thought the above installation would solve my problems.
However, the option seems to be ignored.
My latest iteration uses an extension dependency on remote-ssh to install it. There's a new problem: how to get the correct version of my extension onto the remote host. By default the remote host uses the marketplace version, which obviously won't be the version we're trying to test.
I would first try with only one --install-extension option, just to check if any extension is installed.
I would also check if the same set of commands works locally (install VSCode and its remote SSH extension)
Testing it locally (with only one extension) also allows to check if that extension has any dependencies (like Remote SSH - Editing)

Why npm run serve is throwing ERR_OSSL_EVP_UNSUPPORTED? [duplicate]

This question already has answers here:
Error message "error:0308010C:digital envelope routines::unsupported"
(50 answers)
Closed 12 months ago.
I'm having an issue with a Webpack build process that suddenly broke, resulting in the following error...
<s> [webpack.Progress] 10% building 0/1 entries 0/0 dependencies 0/0 modules
node:internal/crypto/hash:67
this[kHandle] = new _Hash(algorithm, xofLen);
^
Error: error:0308010C:digital envelope routines::unsupported
at new Hash (node:internal/crypto/hash:67:19)
at Object.createHash (node:crypto:130:10)
at BulkUpdateDecorator.hashFactory (/app/node_modules/webpack/lib/util/createHash.js:155:18)
at BulkUpdateDecorator.update (/app/node_modules/webpack/lib/util/createHash.js:46:50)
at OriginalSource.updateHash (/app/node_modules/webpack-sources/lib/OriginalSource.js:131:8)
at NormalModule._initBuildHash (/app/node_modules/webpack/lib/NormalModule.js:888:17)
at handleParseResult (/app/node_modules/webpack/lib/NormalModule.js:954:10)
at /app/node_modules/webpack/lib/NormalModule.js:1048:4
at processResult (/app/node_modules/webpack/lib/NormalModule.js:763:11)
at /app/node_modules/webpack/lib/NormalModule.js:827:5 {
opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
library: 'digital envelope routines',
reason: 'unsupported',
code: 'ERR_OSSL_EVP_UNSUPPORTED'
}
command terminated with exit code 1
I've tried googling ERR_OSSL_EVP_UNSUPPORTED webpack which yielded almost no useful results, but it did highlight an issue using MD4 as provided by OpenSSL (which is apparently deprecated?) to generate hashes.
The webpack.config.js code is as follows:
const path = require('path');
const webpack = require('webpack');
/*
* SplitChunksPlugin is enabled by default and replaced
* deprecated CommonsChunkPlugin. It automatically identifies modules which
* should be splitted of chunk by heuristics using module duplication count and
* module category (i. e. node_modules). And splits the chunks…
*
* It is safe to remove "splitChunks" from the generated configuration
* and was added as an educational example.
*
* https://webpack.js.org/plugins/split-chunks-plugin/
*
*/
/*
* We've enabled TerserPlugin for you! This minifies your app
* in order to load faster and run less javascript.
*
* https://github.com/webpack-contrib/terser-webpack-plugin
*
*/
const TerserPlugin = require('terser-webpack-plugin');
module.exports = {
mode: 'development',
entry: './src/js/scripts.js',
output: {
path: path.resolve(__dirname, 'js'),
filename: 'scripts.js'
},
devtool: 'source-map',
plugins: [new webpack.ProgressPlugin()],
module: {
rules: []
},
optimization: {
minimizer: [new TerserPlugin()],
splitChunks: {
cacheGroups: {
vendors: {
priority: -10,
test: /[\\/]node_modules[\\/]/
}
},
chunks: 'async',
minChunks: 1,
minSize: 30000,
name: 'true'
}
}
};
How do I change the hashing algorithm used by Webpack to something else?
I was able to fix it via:
export NODE_OPTIONS=--openssl-legacy-provider
sachaw's comment to Node.js v17.0.0 - Error starting project in development mode #30078
But they say they fixed it: ijjk's comment to Node.js v17.0.0 - Error starting project in development mode #30078:
Hi, this has been updated in v11.1.3-canary.89 of Next.js, please update and give it a try!
For me, it worked only with the annotation above.
I also want to point out that npm run start works with -openssl-legacy-provider, but npm run dev won't.
It seems that there is a patch:
Node.js 17: digital envelope routines::unsupported #14532
I personally downgraded to 16-alpine.
I had this problem too. I'd accidentally been running on the latest Node.js (17.0 at time of writing), not the LTS version (14.18) which I'd meant to install. Downgrading my Node.js install to the LTS version fixed the problem for me.
There is a hashing algorithm that comes with Webpack v5.54.0+ that does not rely on OpenSSL.
To use this hash function that relies on a npm-provided dependency instead of an operating system-provided dependency, modify the webpack.config.cjs output key to include the hashFunction: "xxhash64" option.
module.exports = {
output: {
hashFunction: "xxhash64"
}
};
Ryan Brownell's answer is the ideal solution if you are using Webpack v5.54.0+.
If you're using an older version of Webpack, you can still solve this by changing the hash function to one that is not deprecated. (It defaults to the ancient md4, which OpenSSL has removed support for, which is the root cause of the error.) The supported algorithms are any supported by crypto.createHash. For example, to use SHA-256:
module.exports = {
output: {
hashFunction: "sha256"
}
};
Finally, if you are unable to change the Webpack configuration (e.g., if it's a transitive dependency which is running Webpack), you can enable OpenSSL's legacy provider to temporarily enable MD4 during the Webpack build. This is a last resort. Create a file openssl.cnf with this content…
openssl_conf = openssl_init
[openssl_init]
providers = provider_sect
[provider_sect]
default = default_sect
legacy = legacy_sect
[default_sect]
activate = 1
[legacy_sect]
activate = 1
…and then set the environment variable OPENSSL_CONF to the path to that file when running Webpack.
It is not my answer really, but I found this workaround /hack/ to fix my problem Code Check in for a GitHub project... see the bug comments here.
I ran into ERR_OSSL_EVP_UNSUPPORTED after updating with npm install.
I added the following to node_modules\react-scripts\config\webpack.config.js
const crypto = require("crypto");
const crypto_orig_createHash = crypto.createHash;
crypto.createHash = algorithm => crypto_orig_createHash(algorithm == "md4" ? "sha256" : algorithm);
I tried Ryan Brownell's solution and ended up with a different error, but this worked...
This error is mentioned in the release notes for Node.js 17.0.0, with a suggested workaround:
If you hit an ERR_OSSL_EVP_UNSUPPORTED error in your application with Node.js 17, it’s likely that your application or a module you’re using is attempting to use an algorithm or key size which is no longer allowed by default with OpenSSL 3.0. A command-line option, --openssl-legacy-provider, has been added to revert to the legacy provider as a temporary workaround for these tightened restrictions.
I ran into this issue using Laravel Mix (Webpack) and was able to fix it within file package.json by adding in the NODE_OPTIONS=--openssl-legacy-provider (referenced in Jan's answer) to the beginning of the script:
package.json:
{
"private": true,
"scripts": {
"production": "cross-env NODE_ENV=production NODE_OPTIONS=--openssl-legacy-provider node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js"
},
"dependencies": {
...
}
}
Try upgrading your Webpack version to 5.62.2.
I faced the same challenge, but you just need to downgrade Node.js to version 16.13 and everything works well. Download LTS, not the current on Downloads.
I had the same problem with my Vue.js project and I solved it.
macOS and Linux
You should have installed NVM (Node Version Manager). If you never had before, just run this command in your terminal:
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash
Open your project
Open the terminal in your project
Run the command nvm install 16.13.0 or any older version
After the installation is completed, run nvm use 16.13.0
I faced the same problem in a project I developed with Next.js. For the solution, I ran the project as follows and I solved the problem.
cross-env NODE_OPTIONS='--openssl-legacy-provider' next dev
This means that you have the latest Node.js version. If you are using it for Docker then you need to change the image from
FROM node
to
FROM node:14

Is it possible to --disable-web-security on Travis Chrome?

I am developing a project which requires --disable-web-security for testing. I use Karma with the following settings:
browsers: [
"ch"
],
customLaunchers: {
"ch": {
"base": "Chrome",
"flags": ["--disable-web-security"]
}
},
and
if (process.env.TRAVIS)
options.customLaunchers.ch.flags.push("--no-sandbox");
This works properly on localhost with Chrome v69.0.3497.100 win7 x64.
I am trying to run the same code on Travis (by pushing the changes to GitHub) with the following yml:
language: node_js
node_js:
- "9"
before_install:
- export CHROME_BIN=chromium-browser
- export DISPLAY=:99.0
- sh -e /etc/init.d/xvfb start
- sleep 5
I guess we are talking about 2 different browsers with the same engine here, since Chromium != Chrome, but I am not sure. Anyways, I got an error message by trying to build on Travis:
Blocked a frame with origin "http://localhost:9876" from accessing a cross-origin frame.
That clearly indicates that web security is enabled. Is there any way to disable web security on Travis?
Solution:
Using Trusty with real Chrome solved it:
language: node_js
node_js:
- "9"
dist: trusty
addons:
chrome: stable
before_install:
- export DISPLAY=:99.0
- sh -e /etc/init.d/xvfb start
- sleep 5
According to this documentation you can run Chrome headless by writing the following in your .travis.yml config file
dist: trusty
addons:
chrome: stable
before_install:
- # start your web application and listen on `localhost`
- google-chrome-stable --headless --disable-gpu --remote-debugging-port=9222 http://localhost &
As for your Karma configuration file, check this page. It indicates that you have to add one more flag.
For security reasons, Google Chrome is unable to provide sandboxing when it is running in the container-based environment.
To use Chrome in the container-based environment, pass the --no-sandbox flag to the chrome executable.
module.exports = function(config) {
config.set({
browsers: ['Chrome', 'ChromeHeadless', 'ChromeHeadlessNoSandbox'],
// you can define custom flags
customLaunchers: {
ChromeHeadlessNoSandbox: {
base: 'ChromeHeadless',
flags: ['--no-sandbox']
}
}
})
}
Be aware that I have Never done this before. I am just pointing you to the correct documentation.

Setting up Protractor with Microsoft Edge

I use CucumberJs and Gulp to run my e2e tests; However, I need to run them against Microsoft Edge. When I do gulp protractor, it successfully opens up both Chrome and Firefox, since neither of them require any drivers like IEDriver.exe or EdgeDriver.exe.
Could anyone point me to an article or show the steps below if it's simple on how to set up Protractor with Microsoft Edge?
I'm trying to achieve parallelism by executing my tests on multiple browsers; this is what my config looks like:
exports.config = {
framework: 'cucumber',
shardTestFiles: true,
maxInstances: 2,
multiCapabilities: [
{
'browserName': 'MicrosoftEdge',
'platform': 'windows',
}
},
{
'browserName': 'firefox',
loggingPrefs: {
driver: 'DEBUG',
server: 'INFO',
browser: 'ALL'
}
}],
//more configs here
}
I achieved the config right above, to run protractor e2e tests in parallel, using this article: http://blog.yodersolutions.com/run-protractor-tests-in-parallel/
Also one for IE driver would be just as helpful if you don't know how to set up Edge.
UPDATES:
From this link: https://msdn.microsoft.com/en-us/library/mt188085(v=vs.85).aspx; under the
Enabling WebDriver with Microsoft Edge:
Download a WebDriver language binding of your choice. Currently C# and
Java Selenium language bindings are supported.
I'm not using Java or C#, I am only using Javascript (Protractor); does that mean that the language binding for Javascript currenlty does NOT work for Edge browser?
In other words, we currently cannot automate the Edge browser using Protractor (Javascript)?
Any help much appreciated and I'll update this post if I find anything pertaining to setting up Protractor with Edge, been looking around the web for hours now.
After some struggle, I got Protractor to work on Microsoft Edge on my Windows 10 system.
Note: I'm using the Jasmine2 framework instead of Cucumber, but I believe the steps below should work for Cucumber as well. I'll try with Cucumber later and update here.
Here are the steps:
Get the Microsoft EdgeHTML version number in use in your system. In my case it is 15.15063. Take a note of the release number here. In this case it is 15063.
(Q.: How to get the Microsoft EdgeHTML version number?
A.: Edge browser > ... > Settings > About this app)
download the correct Release of MicrosoftWebDriver.exe from https://developer.microsoft.com/en-us/microsoft-edge/tools/webdriver/
In my case I downloaded Release 15063. If you get the wrong release, then you are likely to run into an error like this error:
"This version of MicrosoftWebDriver.exe is not compatible with the installed version of Windows 10."
place the MicrosoftWebDriver.exe in the folder where the other drivers are like:
C:\Users\yourname\AppData\Roaming\npm\node_modules\protractor\node_modules\webdriver-manager\selenium\
Adjust your conf.js file. Essentially, this is what conf.js should have:
seleniumAddress: 'http://localhost:4444/wd/hub',
capabilities: // or multiCapabilities:
{
'browserName': "MicrosoftEdge"
}
start the webdriver-manager like this:
C:\your\path>webdriver-manager start --edge C:\Users\yourname\AppData\Roaming\npm\node_modules\protractor\node_modules\webdriver-manager\selenium\MicrosoftWebDriver.exe
You are all set to run your Protractor tests on the Edge browser.
Good Luck!
In windows to download the MicrosoftEdge Webdriver for the HTML version >= 18 then follow the below steps
Open Command Prompt, issue the following command and wait until operation gets completed
DISM.exe /Online /Add-Capability /CapabilityName:Microsoft.WebDriver~~~~0.0.1.0
Open the File Explorer and navigate to C:\Windows\WinSxS and search for MicrosoftWebDriver and it will display two results, copy the webdriver from the amd64_microsoft-webdriver-server-components10.0.18362.1_none and paste it in
/c/Users/Administrator/AppData/Roaming/npm/node_modules/protractor/node_modules/webdriver-manager/selenium
(Note: Using git bash, it's easy to copy the Webdriver)
In the config file of Edge browser, make the following changes
seleniumArgs:['-Dwebdriver.edge.driver=C:\\Users\\Administrator\\AppData\\Roaming\\npm\\node_modules\\protractor\\node_modules\\webdriver-manager\\selenium\\MicrosoftWebDriver.exe'],
capabilities: {
'browserName': 'MicrosoftEdge',
'maxInstances': 1,
'platformName': 'windows',
'nativeEvents': false,
shardTestFiles: true,
},
Open the command prompt, and navigate to project repo and issue the following command to start the edge session
webdriver-manager start --edge "C:\Users\Administrator\AppData\Roaming\npm\node_modules\protractor\node_modules\webdriver-manager\selenium\MicrosoftWebDriver.exe"
I'm using Angular 9 with Edge 89 within linux
The following config worked for me
exports.config = {
directConnect: true,
chromeDriver: '/path/to/ms-edge/webdriver'
capabilities: {
browserName: 'chrome',
chromeOptions: {
binary: '/usr/bin/microsoft-edge'
}
},
},
Official WebDriver can be found here
Since Edge uses Chromium engine, we can reuse all chrome configs and just replace WebDriver and binary path.
Looks like the Protractor folks are now working on adding Edge support for Protractor. Take a look at the recently opened issue on GitHub.
Download the correct release of EdgeHTML webdriver ( https://developer.microsoft.com/en-us/microsoft-edge/tools/webdriver/ ), then settup the conf.js as:
seleniumArgs: ['-Dwebdriver.edge.driver=C:\\Program Files (x86)\\Microsoft Web Driver\\MicrosoftWebDriver.exe'],
Capabilities: {
'browserName': 'MicrosoftEdge',
'maxInstances': 1,
'platformName': 'windows',
'nativeEvents': false,
}
Now Microsoft Edge is supported on Mac Operating System. So to setup in Mac follow below steps
Download the MicrosoftEdge WebDriver from the following link according to version of the edge browser configured in Mac
https://developer.microsoft.com/en-us/microsoft-edge/tools/webdriver/
Unzip the folder and copy the Unix executable file to following path
/usr/local/lib/node_modules/protractor/node_modules/webdriver-manager/selenium/MicrosoftWebDriver
In the config file add SeleniumArgs attribute and capabilities
seleniumArgs : ['-Dwebdriver.edge.driver=/usr/local/lib/node_modules/protractor/node_modules/webdriver-manager/selenium/MicrosoftWebDriver'],
capabilities: {
browserName: 'MicrosoftEdge',
platformName: 'Mac OS X',
browserVersion: '79.0.309.65',
maxInstances: 1,
shardTestFiles: true,
elementScrollBehavior: 1,
nativeEvents: false
},
In order to start the web driver with Edge Session, use below command..
java -jar -Dwebdriver.edge.driver=/usr/local/lib/node_modules/protractor/node_modules/webdriver-manager/selenium/MicrosoftWebDriver /Users//Desktop/Project/node_modules/webdriver-manager/selenium/selenium-server-standalone-3.141.59.jar -port 4444
Edge won't work with directconnect: true. Please refer below example.
directConnect: false,
multiCapabilities: [
{​​​​​
browserName: 'chrome',
chromeOptions: {​​​​​
args: ['--disable-popup-blocking'],
}​​​​​
}​​​​​,
{​​​​​
browserName: 'firefox'
}​​​​​,
{​​​​​
browserName: 'MicrosoftEdge'
}​​​​​
],
jvmArgs: [
'-Dwebdriver.chrome.driver=./src/driver/chromedriver_87.0.4280.20.exe',
`-Dwebdriver.edge.driver=${edgeDriver}`,
'-Dwebdriver.gecko.driver=./src/driver/geckodriver-v0.28.0.exe'
],
Use below code outside config if using mac
const edgeDriver =
process.platform === 'darwin'
? './src/driver/edgedriver_mac64_87.0.664.47/msedgedriver'
: './src/driver/msedgedriver.exe';

Karma - Chrome failed 2 times (cannot start). Giving up

I've been trying to run my tests using karma-chrome-launcher, but everytime I run my tests it throws this error:
INFO [launcher]: Starting browser Chrome
ERROR [launcher]: Cannot start Chrome
INFO [launcher]: Trying to start Chrome again (1/2).
ERROR [launcher]: Cannot start Chrome
INFO [launcher]: Trying to start Chrome again (2/2).
ERROR [launcher]: Cannot start Chrome
ERROR [launcher]: Chrome failed 2 times (cannot start). Giving up.
Here's my karma.conf.js code:
// Karma configuration
// Generated on Mon Mar 23 2015 14:04:19 GMT-0300 (BRT)
module.exports = function(config) {
config.set({
// base path that will be used to resolve all patterns (eg. files, exclude)
basePath: 'www',
// frameworks to use
// available frameworks: https://npmjs.org/browse/keyword/karma-adapter
frameworks: ['jasmine'],
// list of files / patterns to load in the browser
files: [
'lib/ionic/js/angular/angular.js',
'lib/ionic/js/angular/angular-animate.js',
'lib/ionic/js/angular/angular-sanitize.js',
'../node_modules/jasmine-core/lib/jasmine-core/jasmine.js',
'../node_modules/mock-local-storage/lib/mock-localstorage.js',
'../node_modules/angular-mocks/angular-mocks.js',
//'../node_modules/requirejs/require.js',
'lib/ionic/js/angular/angular-resource.js',
'lib/ionic/js/angular-ui/angular-ui-router.js',
'lib/ionic/js/ionic.js',
'lib/ionic/js/ionic-angular.js',
/*'../tests/libs/ngCordovaMocks.min.js',*/
'js/lib/ng-cordova.min.js',
'js/*.js',
'js/controllers/*.js',
'js/services/*.js',
'js/factory/*.js',
//'../tests/*.js',
'../tests/**/*.js'
],
// list of files to exclude
exclude: [
],
// preprocess matching files before serving them to the browser
// available preprocessors: https://npmjs.org/browse/keyword/karma-preprocessor
preprocessors: {
},
// test results reporter to use
// possible values: 'dots', 'progress'
// available reporters: https://npmjs.org/browse/keyword/karma-reporter
reporters: ['progress', 'html'],
htmlReporter: {
outputFile: '../tests/report/index.html'
},
// web server port
port: 9876,
plugins : [
'karma-junit-reporter',
'karma-jasmine',
'karma-phantomjs-launcher',
'karma-chrome-launcher'
//'karma-htmlfile-reporter'
],
// enable / disable colors in the output (reporters and logs)
colors: true,
// level of logging
// possible values: config.LOG_DISABLE || config.LOG_ERROR || config.LOG_WARN || config.LOG_INFO || config.LOG_DEBUG
logLevel: config.LOG_INFO,
// enable / disable watching file and executing tests whenever any file changes
autoWatch: true,
// start these browsers
// available browser launchers: https://npmjs.org/browse/keyword/karma-launcher
browsers: ['PhantomJS'],
// Continuous Integration mode
// if true, Karma captures browsers, runs the tests and exits
singleRun: false
});
};
I'm installing the module here: https://www.npmjs.com/package/karma-chrome-launcher
Thanks!
I had the same problem and tried a lot of the suggested solutions I found, but what finally solved it for me was to delete the node_modules folder and getting everything new via npm install.
Had the same issue with my build environment.
What i did is to follow the advice of Rafael Cichocki to enable the debugging:
logLevel: config.LOG_DEBUG
Then tried to launch the chrome-browser with exactly the same line that was visible int he debug output.
Turned out that chrome browser was crashing due to missing ttf fonts. So running:
apt-get install ttf-freefont
Solved that issue for me and karma started to launch chrome.
In Karma.conf.js, Increase timeouts to 60000
captureTimeout: 60000,
browserDisconnectTimeout: 60000,
browserDisconnectTolerance: 3,
browserNoActivityTimeout: 60000,
browsers: ['PhantomJS'], Here allowed browser is PhantomJs, but code is trying for Chrome, which is not a specified browser in the karma.conf.js.
Change karma.conf.js file :
browsers: ['PhantomJS','Chrome', 'ChromeHeadless'],
chrome- is for opening new chrome browser window.
ChromeHeadless- is for running tests without opening browser window
make sure Chrome is installed and added to PATH
Hope this helps
I noticed when I had this error that when I changed the spec file and saved it, it seemed to work again. I had a few errors in typescript that didn't break the tests (passing in null arguments to a virtual component instance constructor). I don't know if it was resolving the errors since they existed before when it was working, or if changing the file and saving it updated the cache.
So this could mean that clearing the cache in Chrome could also potentially resolve it. It's working now again for me so I can't check to verify.
Just in case you are running this behind a corporate proxy. Make sure you include your 0.0.0.0 in your NO_PROXY Environment variable.
Otherwise your test will first go out through your firewall where it will most likely not be able to reach 0.0.0.0. So just to be sure I include the following in my
NO_PROXY=127.0.0.1,localhost,0.0.0.0
Especially if you are running your tests in a container environment (e.g. your build pipeline) non set environment variables might be a common reason for ng test working fine on your local machine but failing to connect to google-chrome in the container.
If someone faces this error only in gitlab-runner (but in shell by hand ng test work ok), you can apply decision from here:
https://forum.gitlab.com/t/running-karma-tests-with-chrome-and-gitlab-ci/14476
The decision is: in karma.config.js, replace the section
browsers: ['Chrome'],
by
browsers: ['ChromeHeadlessNoSandbox'],
customLaunchers: {
ChromeHeadlessNoSandbox: {
base: 'ChromeHeadless',
flags: ['--no-sandbox']
}
},
The reason of error is that Chrome doesn't support no-sandbox anymore
I got my inspiration partially from here: https://stackoverflow.com/a/33802985/1534823
Also use logLevel: config.LOG_DEBUG - it can help you get good information on what is causing your error`
Check following settings in karma.conf:
captureTimeout: 60000,
browserNoActivityTimeout: 360000
browser: ["Firefox"]
captureTimeout - your browser may take some time to start. LOG_DEBUG should show some error related to capturing your browser
browserNoActivityTimeout - PhantomJS is really slow(x10) on my machine, in comparison to Firefox and Chrome. Karma may timeout before your tests complete.
browser - our jenkins server runs on linux, where we had no binaries for chrome, so we had to switch to firefox
If any of these three settings were not set correctly, we would get the error you described above.
I was able to resolve this by remove the absolute path (src/examplePath) and changing it to a relative path (../../examplePath).
Example change in spec:
import { myPackage } from 'src/myPath'; (seems to be the issues)
import { myPackage } from '../../../myPath'; (seems to resolve it)
Note I had tried deleting the node modules and npm installing but that didn't work. I'm so not sure why this matters.
In Windows Chrome was install to %LOCALAPPDATA%/Google/Chrome/Application earlier. Now it's install to %PROGRAMFILES%/Google/Chrome/Application. If you is very long time with Chrome then your have old version in %LOCALAPPDATA%/Google/Chrome/Application.
Karma-launcher is searches Chrome location in order LOCALAPPDATA->PROGRAMFILES-> 'PROGRAMFILES(X86)' , first found old version and try to run it.
Just delete %LOCALAPPDATA%/Google/Chrome/Application folder
Solution for us with angular cli was setting the following properties in the karma.conf.js
autoWatch: false,
singleRun: true
I was also facing this issue. I made below three changes in my karma.config.js file.
autoWatch: false,
browsers: ['Chrome'],
singleRun: false
I experienced this after updating macOS to Catalina. I solved it by updating Puppeteer to the latest version.
What worked for me:
npm un karma-chrome-launcher
npm i karma-chrome-launcher
npm i -g karma-cli
karma init (and follow the prompts)
ng test --watch=false
Using the watch flag set to false in combination with adjustment of the following parameters in karma.config.js worked for me:
browsers: ['ChromeHeadlessNoSandbox'],
customLaunchers: {
ChromeHeadlessNoSandbox: {
base: 'ChromeHeadless',
flags: ['--no-sandbox']
}
},
I faced a similar issue recently.
And found two solutions to fix this problem.
I installed puppeteer and added process.env.CHROME_BIN = require('puppeteer').executablePath() at the top of my karma.conf.js file, as documented here.
I uninstalled Google Chrome and cleared up all the system folders (%Local Appdata%\Google and also from Program Files / Program Files x86), restarted by the system, and then installed Chrome x64 from the official site.
I was happy with the 1st solution as well, but since I wanted to fix the root problem, I went ahead and found the second solution as well.
Hope this solves the problem for anyone facing this issue.