I have multiple feature files and I would really love to run just one file or just one scenario or just one tag.
I know I could just provide one file in my specs in my cucumberConf.js, but I would like to run it once without fiddling with my cucumberConf.js.
Which arguments do I need to type in when running protractor?
in protractor's config:
cucumberOpts: {
...
tags: [
"#runThis",
"#runThat",
"~#ignoreThis"
];
...
},
in the feature file
#runThis
Scenario: Run this Scenario
Given user does some action
Then something should happen
#ignoreThis
Scenario: ignore this Scenario
Given user does some action
Then something should happen
The easiest way to do this would be to use the --specs option.
protractor --specs=specs/testA.js e2e-conf.js
use the specs array in protractor config file. E.g.
specs: [ 'test/features/xxx.feature' ],
Related
So, my understanding is that react-snap as per its features "Works out-of-the-box with create-react-app - no code-changes required."
I read through the documentation and I see that it required some adjusting to work with Google Analytics which I implemented.
However, it also suggests changes to be made if one is going to use the default service worker that comes with CRA.
https://github.com/stereobooster/react-snap#service-workers
However, what is confusing is that it seems one has to perform a EJECT in order to make the necessary change.
navigateFallback: publicUrl + '/index.html',
You need to change this to an un-prerendered version of index.html - 200.html, otherwise you will see index.html flash on other pages (if you have any). See Configure sw-precache without ejecting for more information.
My question is - and note I am quite novice - does one have to eject? I kinda want to keep things simple. The only place I could find this line was in WebPack. navigateFallback
Also, if I don't see the negative side of the flashes on pages as per the documentation, is it okay to omit this step or will it have issues on other things?
Although this question is more than a year old, I'd like to take the opportunity as I've been able to implement service workers in react-snap (although with a varying degree of success).
Here's stereobooster's reference in GitHub:
https://github.com/stereobooster/react-snap/blob/master/doc/recipes.md#configure-sw-precache-without-ejecting
You can configure it without ejecting. What you need to do is the following:
Download and install sw-precache and ugfify-js:
npm install sw-precache uglify-js --save-dev
or
yarn add sw-precache uglify-js -D
Then, in your package.json add the following entries:
(Replace the build script with the following)
"scripts": {
"generate-sw": "sw-precache --root=build --config scripts/sw-precache-config.js && uglifyjs build/service-worker.js -o build/service-worker.js",
"build": "react-scripts build && react-snap && yarn run generate-sw"
}
Then, create a folder in the root level (next to your package.json) called scripts
and add sw-precache-config.js file.
module.exports = {
// a directory should be the same as "reactSnap.destination",
// which default value is `build`
staticFileGlobs: [
"build/static/css/*.css",
"build/static/js/*.js",
"build/shell.html",
"build/index.html"
],
stripPrefix: "build",
publicPath: ".",
// there is "reactSnap.include": ["/shell.html"] in package.json
navigateFallback: "/shell.html",
// Ignores URLs starting from /__ (useful for Firebase):
// https://github.com/facebookincubator/create-react-app/issues/2237#issuecomment-302693219
navigateFallbackWhitelist: [/^(?!\/__).*/],
// By default, a cache-busting query parameter is appended to requests
// used to populate the caches, to ensure the responses are fresh.
// If a URL is already hashed by Webpack, then there is no concern
// about it being stale, and the cache-busting can be skipped.
dontCacheBustUrlsMatching: /\.\w{8}\./,
// configuration specific to this experiment
runtimeCaching: [
{
urlPattern: /api/,
handler: "fastest"
}
]
};
Note, if you're not using an app-shell but you're loading the whole page (Meaning there's no dyanmic content), replace where it says navigateFallback: "/shell.html" with navigateFallback: "/200.html"
This basically allows you to cache the entire page
You can look for more information here:
https://github.com/stereobooster/an-almost-static-stack
One thing that I'd recommend to check (I'm close to start that process as well) is the workbox-sw.
What to do if React-Snap fails
error at / TypeError: Cannot read property 'ok' of null
Or
ERROR: The process with PID 38776 (child process of PID 26920) could not be terminated. \node_modules\minimalcss\src\run.js:13:35)
Reason: There is no running instance of the task.
You may get these infamous errors. I don't know exactly what causes them, but I know they're mentioned here, and here. In this case, delete the build folder, open a new terminal window, and try again.
If the problem still persists, then break down the script:
Do:
"scripts": {
"build": "react-scripts build"
"postbuild": "react-snap",
"generate-sw": "sw-precache --root=build --config scripts/sw-precache-config.js && uglifyjs build/service-worker.js -o build/service-worker.js",
}
And try running them independently.
I want to run feature files in a desired order or sequence, for example:
tags:"`#ProtractorScenario` or #CucumberScenario"
But cucumber scenario is getting executed first. Can someone guide me on this?
Note: Cucumber is executing scenario based on alphabetical order of feature file in folder
Also, in cases with more than 50+ feature files, what would be the best way to define sequencing of cucumber feature files?
In order to have reliable tests, your tests should be independent and not rely on the order they are run in. The reason being that your test shouldn't depend on the system being in a certain state, as this will lead to flaky tests. Each of your tests should set up the expected state (and teardown!), so they can be run independently.
Below is how protractor executes cucumber feature files:
Protractor finds out all feature files specified in specs, save the absolute file path into an array, let's call it feature_list.
Protractor starts a session (start a browser instance)
Protractor generates a Cucumber CLI as below, and execute the CLI to hand over the running control cucumber:
./node_modules/bin/cucumber --require xxx --format xxx feature1,feature2,....featureN
feature1,feature2,....featureN calculated by feature_list.join(',')
From above, we can learn the only opportunity to change the order
is given an order-done feature_list to protractor specs.
Note: every member of the feature_list should be absolute/relative
path of single feature file. folder and wildcard are not recommended to appear in the path.
You can get a solution code from my github: spec.filter.js, which implements:
filter feature file by cucumberOpts.tags
order filter result of above step 1 by priority
Guide to use spec.filter.js:
// protractor conf file
const specFilter = require('./spec.filter.js');
var config = {
seleniumAddress: 'xxxxx',
capabilities:'xxxx',
framework: 'custom',
frameworkPath: require.resolve('protractor-cucumber-framework'),
ignoreUncaughtExceptions: true,
specs: [
'./aa/**/*.feature',
'./bb/**/*.feature'
],
cucumberOpts: {
require: [
'xxx'
],
priorities: {
// feature has tag #SPGC-21542 or #SPGC-21944 or #SPGC-21946
// will has priority 1
'1': ['#SPGC-21542 or #SPGC-21944', '#SPGC-21946'],
// feature has tag #SPGC-22055 will has priority 2,
// feature has heighest priority will put ahead at
// the `specs` list and get executed firstly.
'2': ['#SPGC-22055']
}
tags: ""
}
....
};
exports.config = specFilter(config);
I am trying to get flow to type check my code but it is giving me an error when it can't find paths that have been rewritten using babel-plugin-module-alias.
I have unsuccessfully tried to use the resolve_dirname option in the flowconfig.
Can someone please tell me if it is possible to use this babel plugin with flow?
.babelrc
{
"plugins": [
"transform-flow-strip-types",
["module-alias", [
{ "src": "./app", "expose": "app" },
]]
]
}
.flowconfig
[options]
module.system.node.resolve_dirname=app
app/main.js
import bar from 'app/foo';
app/main.js:3
3: import bar from 'app/foo';
^^^^^^^^^^ app/foo. Required module not found
module.system.node.resolve_dirname actually tells Flow where to start resolving things from. If you want Flow to resolve starting from 'app', you need to point it one directory higher than app.
Alternatively, you can probably also use `module.name_mapper='^app/([a-z-A-Z0-9$_/]+)$' -> 'src/\1'
Here is how this can be achieved with module.name_mapper setting in .flowconfig [options]. Works in flow version 0.56.0
module.name_mapper='^app/\([-a-zA-Z0-9$_/]+\)$' -> '<PROJECT_ROOT>/src/\1'
In the karma.conf.js you can set what browsers to use e.g. :
browsers: [
"Chrome",
"Firefox",
"IE"
],
Is there anyway in this configuration file to see what the build environment is e.g. Windows or Linux and then only run the tests in the appropriate browsers.
I basically don't want to have to keep changing the config file for karma every time I switch a OS.
After looking into Node.js I found out that you can get the operating system with the following call:
var os = require("os");
With the os variable I was then able to do simple if/else statements with os.type:
if(os.type()==='Linux')
I would then assign the appropriate browser options to the browser array in the config object.
browsers = ["Chrome","Firefox"];
All this logic was done inside the Karam.conf.js file but before the module.exports = function() call.
I have karma config set up correctly, config file, running in the background, just great. As soon as I change and save a file, it reruns the tests.... all 750 of the unit tests. I want to be able to run just a few. Short of manually hacking the config file or commenting out hundreds of tests across many files, is there any easy way to do it?
E.g. when running command line server tests using say mocha, I just use regexp: mocha -g 'only tests that I want'. Makes it much easier to debug and quickly check.
So now I feel foolish. mocha supports a very narrow version of regexp matching.
This runs all tests
describe('all tests',function(){
describe('first tests',function(){
});
describe('second tests',function(){
});
});
This runs just 'first tests'
describe('all tests',function(){
describe.only('first tests',function(){
});
describe('second tests',function(){
});
});
You can also do it.only()
I should have noticed that. Sigh.
You can do that at karma startup time unfortunately, not at runtime.
If you want to change it dynamically you have to put some more effort.
Say you want to focus on a specific set/suite of tests from the beginning, on the karma-mocha plugin page there's this snippet of code to do what you want:
module.exports = function(config) {
config.set({
// karma configuration here
...
// this is a mocha configuration object
client: {
// The pattern string will be passed to mocha
args: ['--grep', '<pattern>'],
...
}
});
};
In order to make the <pattern> parametric you have to wrap the configuration file in a Configurator that will listen CLI and customize the karma configuration for you.
Have a look to this SO answer to know how to setup a very simple Configurator.
I have same question and this is my workround by a little change on karma.conf.js.
In fact, take an argument from command line and modify the pattern in "files".
I use minimist to parse the argument list.
In config file:
/* Begin */
var minimist = require('minimist');
var argv = minimist(process.argv);
var testBase="test/unit";
var testExt=".spec.js";
var unitTestPattern = testBase+'/**/*'+testExt;
if ("test" in argv){
unitTestPattern = testBase+"/"+argv["test"]+testExt;
}
/* End */
module.exports = function(config){
config.set({
//....
files : [
//....
unitTestPattern, //place here
// 'test/unit/**/*.spec.js', //replace this
//....
],
//....
});
};
run in command prompt:
karma start test/karma.conf.js --single-run --test #TEST_CASE_FILE#
a nice extension that can help here is karma-jasmine-html-reporter-livereload
https://www.npmjs.com/package/karma-jasmine-html-reporter-livereload
or karma-jasmine-html-reporter https://www.npmjs.com/package/karma-jasmine-html-reporter?__hstc=72727564.86845f057bb4d741f59d578059e30644.1443860954685.1453095135802.1453138187458.37&__hssc=72727564.1.1453138187458&__hsfp=2285154675
It creates a debug page in which you can run each test individually. very useful for large projects!
1) In your karma.conf.js get the params from the terminal:
var files = (process.env.npm_config_single_file) ? process.env.npm_config_single_file : 'test/test_index.js';
2) In order to run a single test you will need to set an option object with all your configuration (Without files and preprocessors):
var option = {
webpack: {
// webpack configuration
},
// more configuration......
};
3) Set your files path and preprocessors:
option.files = [
{pattern: files, watch: false}
];
option.preprocessors = {};
option.preprocessors[files] = [ 'webpack', 'sourcemap' ];
// call config.set function
config.set(option);
4) Run in the terminal:
npm test --single_file=**/my-specific-file-spec.js
For more information check this PR:
https://github.com/webpack/karma-webpack/pull/178
There are different ways to do it.
Use --grep option. The disadvantage of this is that all the tests are preprocessed before running the specific test suite.
Use .only method. Disadvantage same as no. 1. Using both 1 and 2 method my node process used to crash often saying out of memory.
Limit the files options for processing. This is super fast.
Limit preprocessing to certain folder like Unit or Integration folder.
For this I have used custom cli option --only and in the karma config
const modules = config.only;
and in the the files pattern
files: typeof modules === 'string ? '[`tests/**/${module}/**/*.(test|spec).js`]: 'tests/**/*.(test|spec).js'
Advantage: Developers can run only certain tests when they make a small change way faster by limiting in the preprocessing phase.
You can also use combination of no.3 and no.1 or 2.