canvas-lms/karma.conf.js

147 lines
5.1 KiB
JavaScript
Raw Normal View History

/*
* Copyright (C) 2018 - present Instructure, Inc.
*
* This file is part of Canvas.
*
* Canvas is free software: you can redistribute it and/or modify it under
* the terms of the GNU Affero General Public License as published by the Free
* Software Foundation, version 3 of the License.
*
* Canvas is distributed in the hope that it will be useful, but WITHOUT ANY
* WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
* A PARTICULAR PURPOSE. See the GNU Affero General Public License for more
* details.
*
* You should have received a copy of the GNU Affero General Public License along
* with this program. If not, see <http://www.gnu.org/licenses/>.
*/
// this is because we have a ton of places where people spy/stub es modules
// using sinon and that is not allowed for "real" es modules. you can ony do it
// with babel transpiled stuff
process.env.USE_ES_MODULES = false
const karmaConfig = {
basePath: '',
frameworks: ['qunit'],
proxies: {
'/dist/brandable_css/': '/base/public/dist/brandable_css/',
'/images/': '/base/public/images/'
},
exclude: [],
// 'dots', 'progress', 'junit', 'growl', 'coverage', 'spec'
reporters: ['spec', 'junit'],
eliminate the need to run karma & webpack separately TL;DR: running JS tests in canvas will be a lot faster & simpler What you need to know as a developer writing JS in canvas: Lets say you are working on the “dashboard_cards” feature, just run: `npm run jspec-watch spec/javascripts/jsx/dashboard_card` While you write code and it will have a watcher that catches any changes and re-runs just the dashboar_card specs if you save any file that went into it. It should run & reload in less than a few seconds. You can give it the path to a specific spec file or have it run an entire directory. Or, if you are working on something that might touch a lot of stuff, run: `npm run test-watch` and while you are changing stuff, it will run *all* the QUnit specs on any change. It should only take a couple seconds for webpack to process the file change and to reload the specs in the browser. Jenkins can now just run “npm test” for the webpack build. No need to bundle install then run rake tasks just to run js tests. This change also starts warning you when you have specs that take a long time to run (e.g.: https://cl.ly/2i1O3O0J1504). It turns out we have some *really* slow js specs (like selenium-level slow) so if you notice a slow spec that you our your team wrote, please fix it. Longer details: To test our JS in webpack, we used to 1. run webpack with an env var set so it only does our ember stuff 2. run karma against ember 3. run webpack again against all the rest of the specs canvas 4 run karma again against all the specs in canvas that took a long time. this change makes it so both the ember specs and the specs in the rest of canvas run all in the same karma. it also makes it so karma runs webpack itself. so you don’t need to run `npm run webpack-test && karma start` to run tests, just `npm run test` (which is just an alias to `karma start`). it also means there is now just one watcher (karma) instead of one for both webpack and karma. Closes: CNVS-34977 Test plan: * Jenkins builds should pass * Try running different variations of the commands up there in the description. They should work and be fast-ish. Change-Id: Ia97f9bfa3677763f218f5f02c9463344f180bc6c Reviewed-on: https://gerrit.instructure.com/102169 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-02-14 11:57:26 +08:00
// enable the verbose reporter if you want to have more information of where/how specs fail
// reporters: ['verbose'],
// this is to make a nice "spec failures" report in the jenkins build instead of having to look at the log output
junitReporter: {
outputDir: 'coverage-js/junit-reports',
outputFile: `karma-${process.env.JSPEC_GROUP || 'all'}.xml`,
useBrowserName: false // don't add browser name to report and classes names
},
specReporter: {
maxLogLines: 50, // limit number of lines logged per test
suppressErrorSummary: false, // print error summary
showSpecTiming: true // print the time elapsed for each spec
},
port: 9876,
colors: true,
autoWatch: true,
// - Chrome
// - ChromeCanary
// - ChromeHeadless
// - Firefox
// - Opera (has to be installed with `npm install karma-opera-launcher`)
// - Safari (only Mac; has to be installed with `npm install karma-safari-launcher`)
// - PhantomJS (has to be installed with `npm install karma-phantomjs-launcher`))
// - IE (only Windows; has to be installed with `npm install karma-ie-launcher`)
browsers: ['ChromeWithoutBackground'],
customLaunchers: {
// Chrome will sometimes be in the background when specs are running,
// leading to different behavior with things like event propagation, which
// leads easily to bugs in production and/or spec code. To decrease the
// chances of this, render backgrounding must be disabled when launching
// Chrome.
ChromeWithoutBackground: {
base: 'Chrome',
flags: ['--disable-renderer-backgrounding']
},
// Run headless chrome with `karma start --browsers ChromeHeadlessNoSandbox`
ChromeHeadlessNoSandbox: {
base: 'ChromeHeadless',
flags: ['--no-sandbox', '--disable-renderer-backgrounding'] // needed for running tests in local docker
}
},
// If browser does not capture in given timeout [ms], kill it
captureTimeout: 60000,
browserNoActivityTimeout: 2000000,
eliminate the need to run karma & webpack separately TL;DR: running JS tests in canvas will be a lot faster & simpler What you need to know as a developer writing JS in canvas: Lets say you are working on the “dashboard_cards” feature, just run: `npm run jspec-watch spec/javascripts/jsx/dashboard_card` While you write code and it will have a watcher that catches any changes and re-runs just the dashboar_card specs if you save any file that went into it. It should run & reload in less than a few seconds. You can give it the path to a specific spec file or have it run an entire directory. Or, if you are working on something that might touch a lot of stuff, run: `npm run test-watch` and while you are changing stuff, it will run *all* the QUnit specs on any change. It should only take a couple seconds for webpack to process the file change and to reload the specs in the browser. Jenkins can now just run “npm test” for the webpack build. No need to bundle install then run rake tasks just to run js tests. This change also starts warning you when you have specs that take a long time to run (e.g.: https://cl.ly/2i1O3O0J1504). It turns out we have some *really* slow js specs (like selenium-level slow) so if you notice a slow spec that you our your team wrote, please fix it. Longer details: To test our JS in webpack, we used to 1. run webpack with an env var set so it only does our ember stuff 2. run karma against ember 3. run webpack again against all the rest of the specs canvas 4 run karma again against all the specs in canvas that took a long time. this change makes it so both the ember specs and the specs in the rest of canvas run all in the same karma. it also makes it so karma runs webpack itself. so you don’t need to run `npm run webpack-test && karma start` to run tests, just `npm run test` (which is just an alias to `karma start`). it also means there is now just one watcher (karma) instead of one for both webpack and karma. Closes: CNVS-34977 Test plan: * Jenkins builds should pass * Try running different variations of the commands up there in the description. They should work and be fast-ish. Change-Id: Ia97f9bfa3677763f218f5f02c9463344f180bc6c Reviewed-on: https://gerrit.instructure.com/102169 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-02-14 11:57:26 +08:00
reportSlowerThan: 1000,
// normally QUnit wraps each test in a try/catch so a single spec failing
// doesn't stop the whole test suite. In dev, if you want to click the
// "pause on exception" thing in chrome and have it stop on your failing test, enable notrycatch
// client: {qunit: {notrycatch: true}},
// by default we keep the browser open so it refreshes with any changes
// but in `npm test` (which is what jenkins CI runs) we override it so
// it just runs once and then exits.
singleRun: false,
eliminate the need to run karma & webpack separately TL;DR: running JS tests in canvas will be a lot faster & simpler What you need to know as a developer writing JS in canvas: Lets say you are working on the “dashboard_cards” feature, just run: `npm run jspec-watch spec/javascripts/jsx/dashboard_card` While you write code and it will have a watcher that catches any changes and re-runs just the dashboar_card specs if you save any file that went into it. It should run & reload in less than a few seconds. You can give it the path to a specific spec file or have it run an entire directory. Or, if you are working on something that might touch a lot of stuff, run: `npm run test-watch` and while you are changing stuff, it will run *all* the QUnit specs on any change. It should only take a couple seconds for webpack to process the file change and to reload the specs in the browser. Jenkins can now just run “npm test” for the webpack build. No need to bundle install then run rake tasks just to run js tests. This change also starts warning you when you have specs that take a long time to run (e.g.: https://cl.ly/2i1O3O0J1504). It turns out we have some *really* slow js specs (like selenium-level slow) so if you notice a slow spec that you our your team wrote, please fix it. Longer details: To test our JS in webpack, we used to 1. run webpack with an env var set so it only does our ember stuff 2. run karma against ember 3. run webpack again against all the rest of the specs canvas 4 run karma again against all the specs in canvas that took a long time. this change makes it so both the ember specs and the specs in the rest of canvas run all in the same karma. it also makes it so karma runs webpack itself. so you don’t need to run `npm run webpack-test && karma start` to run tests, just `npm run test` (which is just an alias to `karma start`). it also means there is now just one watcher (karma) instead of one for both webpack and karma. Closes: CNVS-34977 Test plan: * Jenkins builds should pass * Try running different variations of the commands up there in the description. They should work and be fast-ish. Change-Id: Ia97f9bfa3677763f218f5f02c9463344f180bc6c Reviewed-on: https://gerrit.instructure.com/102169 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-02-14 11:57:26 +08:00
files: [
{pattern: 'spec/javascripts/webpack_spec_index.js', included: true, served: true},
{pattern: 'spec/javascripts/fixtures/*', included: false, served: true},
{pattern: 'public/dist/brandable_css/**/*.css', included: false, served: true}
eliminate the need to run karma & webpack separately TL;DR: running JS tests in canvas will be a lot faster & simpler What you need to know as a developer writing JS in canvas: Lets say you are working on the “dashboard_cards” feature, just run: `npm run jspec-watch spec/javascripts/jsx/dashboard_card` While you write code and it will have a watcher that catches any changes and re-runs just the dashboar_card specs if you save any file that went into it. It should run & reload in less than a few seconds. You can give it the path to a specific spec file or have it run an entire directory. Or, if you are working on something that might touch a lot of stuff, run: `npm run test-watch` and while you are changing stuff, it will run *all* the QUnit specs on any change. It should only take a couple seconds for webpack to process the file change and to reload the specs in the browser. Jenkins can now just run “npm test” for the webpack build. No need to bundle install then run rake tasks just to run js tests. This change also starts warning you when you have specs that take a long time to run (e.g.: https://cl.ly/2i1O3O0J1504). It turns out we have some *really* slow js specs (like selenium-level slow) so if you notice a slow spec that you our your team wrote, please fix it. Longer details: To test our JS in webpack, we used to 1. run webpack with an env var set so it only does our ember stuff 2. run karma against ember 3. run webpack again against all the rest of the specs canvas 4 run karma again against all the specs in canvas that took a long time. this change makes it so both the ember specs and the specs in the rest of canvas run all in the same karma. it also makes it so karma runs webpack itself. so you don’t need to run `npm run webpack-test && karma start` to run tests, just `npm run test` (which is just an alias to `karma start`). it also means there is now just one watcher (karma) instead of one for both webpack and karma. Closes: CNVS-34977 Test plan: * Jenkins builds should pass * Try running different variations of the commands up there in the description. They should work and be fast-ish. Change-Id: Ia97f9bfa3677763f218f5f02c9463344f180bc6c Reviewed-on: https://gerrit.instructure.com/102169 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-02-14 11:57:26 +08:00
],
preprocessors: {
'spec/javascripts/webpack_spec_index.js': ['webpack']
},
webpack: require('./webpack.test.config')
}
// For faster local debugging in karma, only add istanbul cruft you've explicity set the "COVERAGE" environment variable
if (process.env.COVERAGE) {
karmaConfig.reporters.push('coverage-istanbul')
karmaConfig.coverageIstanbulReporter = {
reports: ['html', 'json'],
dir: 'coverage-karma/',
fixWebpackSourcePaths: true
}
karmaConfig.webpack.module.rules.unshift({
test: /\.(js|coffee)$/,
use: {
loader: 'istanbul-instrumenter-loader',
options: {esModules: true, produceSourceMap: true}
},
enforce: 'post',
exclude: /(node_modules|spec|public\/javascripts\/(bower|client_apps|translations|vendor|custom_moment_locales|custom_timezone_locales))/
})
}
module.exports = function(config) {
// config.LOG_DISABLE || config.LOG_ERROR || config.LOG_WARN || config.LOG_INFO || config.LOG_DEBUG
karmaConfig.logLevel = config.LOG_INFO
config.set(karmaConfig)
// Allow passing in FORCED_FAILURE=true env variable to force failures in karma specs
config.set({
client: {
args: process.env.FORCE_FAILURE === '1' ? ['FORCE_FAILURE'] : []
}
})
}