I was wondering if it was possible to access the settings defined within my karma.config.js file, and if so how?
I'm currently using a Grunt task runner to perform various tasks like building, linting, packaging, etc. I'm also using Grunt to kick off the Karma test runner to run my Jasmine unit tests. Furthermore, I'm pulling in the Jasmine-jQuery library so I can define and read in JSON and HTML fixtures from separate files that I setup earlier.
While I was writing some new tests, I noticed that I was redefining my fixtures base path in every test file. So I decided to pull it out and put it into a global constant.
The problem I'm having is where I should define it. Currently, I have a file named "testSettings.js" that I'm including in my karma configuration, where I define a configuration object and set it to window.testSettings. Thats all well and good, but I think it would be better if I defined it within my karma configuration and then just referenced that from my tests. But there doesn't look like a way to do this... or is there?
My library versions are:
"karma": "~0.12.32"
"karma-jasmine": "~0.3.5"
"karma-jasmine-jquery": "~0.1.1"
Related
I have multiple spec files for running tests related to each other and to run them easier separately. When I run my cypress test with a junit reporter only test suites of the last spec files are present. We use the junit reporter for jenkins.
Is these some config I need to add to make sure all test suites are present in the junit report file?
This is a known issue in cypress. https://github.com/cypress-io/cypress/issues/1824
You can use [hash] as a workaround to generate multiple test output files, jenkins will automatically compile the results together.
Add this to your cypress.json file:
"reporterOptions": {
"mochaFile": "./cypress/results/cypress-output.[hash].xml"
},
I was hunting for an answer to this question and just learned that if you use Mochawesome as your test reporter, you can use Mochawesome Merge to combine the output of multiple specs and then use Mochawesome Report Generator to create a single HTML report from your specs.
It doesn't seem like Jest allows all the test runs to share a global context for integration testing. It does have globalSetup and globalTeardown options, but it doesn't seem like those hooks are intended to be a shared testing context across all test runs. You can hack something together using these hooks, passing variables through the node process, but then other issues start to arise (Different instances of Array constructors during assertions, etc...).
If I have a fairly heavy integration test setup process, is it recommended that I only have one test run, where all my integration tests would live and have access to the shared context?
Currently my integration tests are spread across multiple files (individual entry points) and import a setup process. However that setup process is getting run once per file. I'm assuming that alternatively I can have one entry point and then import all my integration test files within the same context. Is that a good/recommended option?
What's the recommended way of setting up integration tests for use in Jest?
I've solved this issue using a combination of 2 solutions:
Jest setupTestFrameworkScriptFile: https://jestjs.io/docs/en/23.x/configuration#setuptestframeworkscriptfile-string
NodeJS Global objects: https://stackabuse.com/using-global-variables-in-node-js/
Using the jest one time setup I can execute my setup only once, and store the results as variables in the NodeJS global object.
Example:
// package.json
"jest": {
"setupTestFrameworkScriptFile": "<rootDir>/globalSetupFile.js"
}
// globalSetupFile.js
global.globalUser = createGlobalUser();
// testFile.spec.js
loginAsUser(global.globalUser.email, global.globalUser.password);
I'm trying to leverage GruntJS to create a build process that is uniform across multiple teams and projects at my company. The idea hear is that we have a config file for each application that only specifies the files that need to be processed and what bundles they need to be concatenated into at the end. The build process would be the same for all apps: pick up the config for the app, process files in each bundle using a uniform build process.
For Example:
asset.json config file specifies two bundles, "main" with 1.js + 2.js and "secondary" with 2.js and 3.js
Build process says for each bundle, preprocess, minify, then concatenate into a js file based on the bundle
Get output of "main.js" and "secondary.js"
The problem I'm running into is that Grunt takes a "static" configuration and executes it. I've already abstracted out the building of the configuration so that I can add chunks dynamically, but right now I don't see a better way forward than literally looping over each bundle and building out a unique task for each section of the build process for each bundle, building up queues of tasks to execute, and then running each task in the queues during the build process. Its definitely possible, but its a lot of manual work and seems prone to breaking. Is there way to just execute each task in order as I loop over the bundles? Any better way to achieve the same net result of config + source in, N bundles out?
I want to be clear that I am fully aware that Grunt CAN build multiple files. What I'm trying to do is separate the specification of how many bundles from the build steps themselves. Grunt core has to bake these two things together which means each project would have to go in and alter their build steps rather than an external configuration. As per the example above, I should be able to swap out the asset.json file specified in step 1 for any config file that has 1, 2, 3, ... N bundles with N files in each one (and potentially specifying a "type" like scripts or styles).
Edit 10/12/13: The Nitty Gritty posted an article yesterday that might be another approach to tackling your issue.
This can be done by passing the module name you want to build as a command line argument and loading in the whole assets file in your grunt config. Please note this is example code, I have not tested this, so it's possible you need to set paths etc. correct for your case.
Start with updating the assets.json file to a plain JavaScript file, and reform it like so:
module.exports = {
main: ["1.js", "2.js"],
secondary: ["2.js","3.js"]
}
Next, you can pass a command line argument to Grunt, which should specify one of the module names in assets.js. Example:
grunt --bundle=main
Now, you'll need to load in the assets.js file in the Gruntfile:
var assets = require('./assets'); // assuming assets.js is on the same level as your Gruntfile
And then you can get the argument name by using:
var bundle = grunt.option("bundle");
Now you can use bundle as your output file name and assets.bundle to get the array files for that bundle.
I am running test using a phpunit.xml.dist file. This file defines several test suites and specifies a bootstrap.php. In this bootstrap.php I am currently loading all dependencies for all tests.
A small subset of the tests is dependent on some third party library, which is optional. These tests are all part of a particular test suite. So I only want to load this library in the bootstrapping file when that particular test suite is specified.
How can I determine if this test suite was specified? This then ensures that most tests can be run when the library is not loaded, and that one can easily verify the code and tests that should not depend on the library indeed do not need it.
I currently have the following. Is there something better?
if ( !in_array( '--testsuite=WikibaseDatabaseStandalone', $GLOBALS['argv'] ) ) {
require_once( __DIR__ . '/evilMediaWikiBootstrap.php' );
}
The feature request on the PHPUnit bugtracker for a test suite specific bootstrap is here: https://github.com/sebastianbergmann/phpunit/issues/733
For now there are two options: One is yours which is fine but feels really hackish and doesn't work out well if you run "all the tests" if you have specific bootstrap for every one of them.
My suggestion would be to write a test listener and hook into "startTestSuite" and "endTestSuite". This is a nice maintained and BC compatible way to execute code only when the test suite is actually started and you can also clean up afterwards.
See http://phpunit.de/manual/3.7/en/extending-phpunit.html#extending-phpunit.PHPUnit_Framework_TestListener and http://phpunit.de/manual/3.7/en/appendixes.configuration.html#appendixes.configuration.test-listeners for how to include the test listener.
One of the usual way to handle this is to check if a required dependency is installed, and if not, run
$this->markTestAsSkipped('lib not installed');
That skipping can also happen in the setUp() phase of a test.
Finally, you can add #group annotations to the test-class and/or test functions to give some choice to whether or not the test is run from the command line (with the --group [names...] parameter).
Finally, an option that has also been used in the ZendFramework is to only add the TestSuite that runs a subset within a larger set of a testsuite - in code. There is an example of being able to
a) turn off as will,
b) turn off if the extension is not loaded, or
c) run the tests, for the use of (for example)
caching with APC
I am a newbie to jasmine, please correct me if I am asking a wrong question.
I am working on a legacy system which has a lot java script code. I would like to write some tests for the same. Initially I thought of using buster since it's in beta I didn't explored much about it. Meantime while searching I came across jasmine. Writing tests in jasmine was simple, maven plugin makes jasmine to be integrated with CI also we can get coverage report. So I felt to use jasmine.
In our current legacy systems there are several js, which need's a lot of refactoring . But to start off writing some test.I need some help. Let me narrate the problem I am facing
We have a lot of scripts having conflicting function names, and global variable's and so on. So specifying the jsSource in pom or jstestconf file is cumbersome, as I need to exclude few files, sometimes scripts which needs tests might have a conflicting function name. Also some scripts may be dependent on other's and so on.
Is there a way in jasmine the below mentioned scenario could be achieved.
Test1.js
Include specific library, excluding common once
Include the java script(Source1.js) source which needs to tested
Then write the tests
Test2.js
Include specific library, excluding common once
Include the javascript source(Source2.js) which needs to be tested
to tested
Then write the tests
Something similar to junit's where we say include class which needs to be tested.
Doing some initial search I got to know by using requirejs I can achieve this. But I couldn't find any concrete example's.
I would need your opinion before proceeding further.
Also is there any other testing framework which I use which have good integration with maven & eclipse and better modularity of tests.
I've been using Karma to run jasmine tests, and you can specify the files Karma includes via the karma.conf.js files property. So you could set up 2 different configurations for Test1.js and Test2.js. For example (assuming you have node_modules and your other files are under my-application-root:
for config 1:
module.exports = function(config){
config.set({
basePath : './',
//files to load in the browser
files : [
'my-application-root/specific-library-1.js',
'my-application-root/Source1.js',
'my-application-root/test/Test1.js',
'my-application-root/node_modules/**/*.js'
],
exclude : [
'my-application-root/common-lib.js',
'my-application-root/specific-library-2.js',
],
.......
and for config 2:
module.exports = function(config){
config.set({
basePath : './',
//files to load in the browser
files : [
'my-application-root/specific-library-2.js',
'my-application-root/Source2.js',
'my-application-root/test/Test2.js',
'my-application-root/node_modules/**/*.js'
],
exclude : [
'my-application-root/common-lib.js',
'my-application-root/specific-library-1.js',
],
.......