How can I configure the random option using grunt-contrib-jasmine? I can do it directly with jasmine's command line, but running jasmine's task by grunt-cli I didn't find the random option. Then the output of command line always shows the specs' randomic output.
I found the answer to my question. At least I've tested and it worked.
On the each describe declaration's top, you can configure the random option of your Suit Test. It can be with the following statement:
describe('My suite', function(){
jasmine.getEnv().configure({random:false});
// There are several tests here...
afterAll(function(){
jasmine.getEnv().configure({random:true});
});
...
If you use jasmine.d.ts and your tests are in typescript, you could also add to the Env interface in jasmine.d.ts a funtion like:
interface Env {
// some code
// add function:
configure(b: any): void;
}
Then in your tests you could write something like:
/// <reference path="../../../../typings/jasmine/jasmine.d.ts" />
jasmine.getEnv().configure({ random: false });
I tested this approach and in the end I didn't have to set the random option to false in each describe function. I added it right after the reference paths and it worked for all tests.
Edit: You could also include the jasmine configuration in the options/helpers part of your grunt-contrib-jasmine task as a separate file. Something like:
jasmine: {
src: [some source files],
options: {
specs: [some spec files],
helpers: 'helpers.js'
}
}
Related
I have a scenario where I have a function which we don't want to include in Jest test coverage but we do still want to include it in JSDoc documentation generation. Take the following function for example:
/**
* This is a test function description
* #function
*/
/* istanbul ignore next */
export const myTestFunction = () => {
console.log("testing");
return true;
};
I want that function not to be included in Jest code coverage stats but I do still want that JSDoc to be processed and included in the documentation generated via JSDoc. Adding the istanbul comment seems to cause the function to be ignored for both. Is there an alternate way to tell Jest to exclude this method?
I believe the issue is the JSDoc block is not right above the function (export const) and the comment line is there. Not sure your real world scenario here to try to suggest a work around. One option is to put these types of functions into a separate file and add that file to the Jest configuration for collectCoverageFrom, with a negative file in the glob.
collectCoverageFrom: [
'<rootDir>/**/*.ts',
'!<rootDir>/**/newfunctions.ts', // This is the file you moved the functions into
'!<rootDir>/**/*.module.ts'
],
I just cannot make it up why cucumber does not see the steps.
Here is my structure. Currently only test.feature matters, as i tried to simplify everything:
Here is my test.feature:
Here is my test.steps:
Here is my very much simplified now world.js:
As you can see the steps are not seen by the feature.
Here is the test result:
I tried manipulations with regexps, file names, folder moves, etc. Maybe somebody can give me a hint what else I can try.
EDITED: I added cucumber version used and cucumberOpts:
The root cause is for different Cucumber version, it has different pattern to write step defintion.
You used Cucumber 4, but your step definition pattern is for Cucumber 1.
For Cucumber 3 and 4, step definition should look like:
var {Given, Then, When} = require('cucumber');
When(/^i load the app$/, function(){
...
});
More detail
For Cucumber 2, step definition should look like:
var {defineSupportCode} = require('cucumber');
defineSupportCode(function ({ Given, When, Then }) {
When(/^i load the app$/, function () {
...;
});
}
More detail
For Cucumber 1, step definition should look like:
module.exports = function() {
this.When(/^i load the app$/, function() {
...;
});
};
More detail
FYI, pretty format removed in Cucumber 4, so you can't config it in cucumberOpts:
cucumberOpts: {
format: ['pretty']
}
If you want the pretty back, please install another package: cucumber-pretty, and add it in cucumberOptions:
cucumberOpts: {
format: ['node_modules/cucumber-pretty']
}
More detail
I believe your folder structure is little off. Can you try something like below. I believe you need to have features and step_definitions folders in the same directory for cucumber to find step definitions. If not, you can provide --require parameter and tell cucumber explicitly where your step_definitions are like below
cucumber.js test/features/paypalreg.feature --require test/features/step_definitions/ --format=pretty
I have some complex Mocha code which I would like to statically check with FlowType because why not?
Below is a minimal repro:
/* #flow */
describe('it', function () {
it('fails', function() {
const s: number = 'flow spots this error';
});
});
When I run Flow on this, Flow does indeed spot the problem with the assignment of string to number which shows that the approach is working to some extend.
However, I also get:
test/test.js:4
4: describe('it', function () {
^^^^^^^^ identifier `describe`. Could not resolve name
test/test.js:5
5: it('fails', function() {
^^ identifier `it`. Could not resolve name
… apparently the Mocha test definitions run in an environment where these functions are globally available but looking at the test file there's nothing that would allow Flow to detect that.
I am not sure these problems are specific to Mocha but I don't feel I can confidently frame the question in broader terms, so my questions are:
how can I have Flow type check Mocha test code without suppressing every line that contains describe or it ?
is this is an instance of a broader class of situations and, if so, what would the latter be?
Third-party libraries usually need definition files, i.e. files containing all the type information for a given library.
In this case, you need a definition file for mocha, which fortunately is provided by flow-typed.
Install it with
npm install -g flow-typed
then run
flow-typed install
It will automatically install all the available definition files for your dependencies, including mocha.
You can simply declare the flow describe, it variables.
/* #flow */
declare var describe: any;
declare var it: any;
describe('it', function () {
it('fails', function() {
const s: number = 'flow spots this error';
});
});
Following the lead of this question, I tried (naievely) to do this:
protractor test/features/protractor-conf.js --params.test_set=dev_test
and
protractor-conf.js:
exports.config = {
// ...
specs: [browser.params.test_set+'/*.feature'],
... but of course it doesn't work because browser is not defined at the time that the conf file is parse.
So how could I achieve this effect: passing a parameter to protractor that determines the specs?
Use the --specs command-line argument:
--specs Comma-separated list of files to test
protractor test/features/protractor-conf.js --specs=dev_test/*.feature
Note that dev_test/*.feature would be passed into the protractor's command-line-interface which would resolve the paths based on the current working directory (source code).
So, I've been looking all over for this, found "similar" answers here, but not exactly what I want.
Right now if I want to test a single file with karma, I need to do fit(), fdescribe() on the file in question...
However, what I do want is to be able to just call karma, with the config file, and direct it to a specific file, so I don't need to modify the file at all, ie:
karma run --conf karma.conf.js --file /path/to/specific/test_file.js
is it possible to do this? Or with any helper? (using grunt or gulp?)
First you need to start karma server with
karma start
Then, you can use grep to filter a specific test or describe block:
karma run -- --grep=testDescriptionFilter
Even though --files is no longer supported, you can use an env variable to provide a list of files:
// karma.conf.js
function getSpecs(specList) {
if (specList) {
return specList.split(',')
} else {
return ['**/*_spec.js'] // whatever your default glob is
}
}
module.exports = function(config) {
config.set({
//...
files: ['app.js'].concat(getSpecs(process.env.KARMA_SPECS))
});
});
Then in CLI:
$ env KARMA_SPECS="spec1.js,spec2.js" karma start karma.conf.js --single-run
This option is no longer supported in recent versions of karma:
see https://github.com/karma-runner/karma/issues/1731#issuecomment-174227054
The files array can be redefined using the CLI as such:
karma start --files=Array("test/Spec/services/myServiceSpec.js")
or escaped:
karma start --files=Array\(\"test/Spec/services/myServiceSpec.js\"\)
References
karma-runner source: cli.js
karma-runner source: config.js
I tried #Yuriy Kharchenko's solution but ran into a Expected string or object with "pattern" property error.
Therefore I made the following modifications to his answer and now I'm able to run single files using Karma:
function getSpecs(specList) {
if (specList) {
return specList.toString();
} else {
return ['**/*_spec.js'] // whatever your default glob is
}
}
module.exports = function(config) {
config.set({
//...
files: [
{ pattern: getSpecs(process.env.KARMA_SPECS), type: "module"}
]
});
});
Note: This solution only works with a single file mentioned in the KARMA_SPECS env variable. Ex: export KARMA_SPECS="src/plugins/muc-views/tests/spec1.js"