I guess since our team owns these we can opt them in now
Test plan:
* nothing should change
Change-Id: Ic7207e1033869ef60644c41bd5c80a3e8532a6dd
Reviewed-on: https://gerrit.instructure.com/171471
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Tested-by: Jenkins
QA-Review: Ryan Shaw <ryan@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
This should pick up coverage from both karma and jest
in Canvas proper. It should also pick up coverage from anything under
packages/*
closes CORE-1265
Test Plan:
- Run `COVERAGE=true yarn test`
- Coverage reports (coverage-final.json) should generate in all
packages such as (canvas-planner) as well as in coverage-karma
and coverage-jest
- Run `yarn run test:coverage`
- coverage-js folder should be generated. Opening index.html
should show the full coverage report
- Remove coverage-{js, karma, jest} and
packages/canvas-planner/coverage as well as .nyc_output to get back
to a clean state
- Run `RUN_TESTS_FIRST=true yarn run test:coverage`
- All tests should run and generate the appropriate report just
like the last time in coverage-js
Change-Id: I50744b8977e0683e079af5bdd2865dbcd6ad9066
Reviewed-on: https://gerrit.instructure.com/146098
Tested-by: Jenkins
Reviewed-by: Ryan Shaw <ryan@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Clay Diffrient <cdiffrient@instructure.com>
closes: CORE-865
In order to get accurate coverage reports (ie: so the coverage numbers
don’t only reflect a fraction of the total tests), when the COVERAGE
environment variable is set, it does not split them out into groups to
run concurrently. That way our linters-and-js-master build (which sets
that environment variable) will run the same as it always has and our
patch-set builds (which run the linters-and-js) will be faster.
Test plan:
* run ‘yarn test’
* it should be a lot faster than it used to be
* look at the linters-and-js build in jenkins for this commit
* it should have test reports for all both groups (coffee, js)
Of karma tests as well as for the jest tests.
* look at the coverage report after this gets merged. It should be
the same as it was before
Change-Id: I35147cc84df4afae92c1a73c201667d4d44b5518
Reviewed-on: https://gerrit.instructure.com/136373
Reviewed-by: Simon Williams <simon@instructure.com>
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Reviewed-by: Jeremy Neander <jneander@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Test plan:
* run `yarn test`
* there should be xml file in coverage-js/karma-test-results.xml
With the spec results that we will use for Jenkins builds
Change-Id: Ic68de197d2b52dbccdf58dc2d148aef1f2ca2646
Reviewed-on: https://gerrit.instructure.com/135949
Tested-by: Jenkins
Reviewed-by: Robert Lamb <rlamb@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
the preferred way to do headless testing is now chrome headless and
we have a bunch of tests that don't work in phantom anymore anyway since
they use es6 syntax that phantom's old safari doesn't support.
test plan:
* `yarn test` should still work
Change-Id: I16496ef77fe65ca61bda8c8e18d1c887b6a48486
Reviewed-on: https://gerrit.instructure.com/131340
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Refs: CNVS-38653
This upgrades us to webpack 3.5.4 and upgrades uglify
and Istanbul related stuff too:
Test plan:
* automated build should pass
* run yarn && COVERAGE=1 yarn test && open coverage-js/index.html
* it should run karma & open your browser to a bunch of istambul reports
* run `yarn run webpack-production`
* it should generate minified code that works in your browser when you
open canvas in prod mode
Change-Id: Id8b3c2457f47a30f299eafc6a8206102cfe98dc5
Reviewed-on: https://gerrit.instructure.com/122993
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Test plan: docker-compose run --rm karma yarn test
Change-Id: I316d80e7a1b712b0dda91a390c4dddeb09b3e6fb
Reviewed-on: https://gerrit.instructure.com/122776
Tested-by: Jenkins
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
closes: CNVS-31785
test plan:
all builds should pass
Change-Id: I2925934692a3d2f115f1289d7b50cb72d8cb907f
Reviewed-on: https://gerrit.instructure.com/104492
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
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>
closes: CNVS-34770
because the previous commit renamed
‘module’ to ‘qunit.module’ in all our specs,
we don’t need this loader anymore
in an effort to get rid of vendor code that is just
copy/pasted into our repo, this also has us use
npm to get qunit, sinon, and AXE.
test plan:
* because this only touches stuff for specs,
if js specs pass in both webpack and requireJS,
this should be good.
Change-Id: I1d1cbf187211ad1d04d775fe4469913b3942d74a
Reviewed-on: https://gerrit.instructure.com/101101
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
fixes: CNVS-31779 [webpack] bundle file size
test plan:
* using webpack, look at the network panel in
the chrome developer console.
* the total ammount of javascript loaded for any
given page should be much less than before this commit
and about on par with what requireJS loads for the same page.
* use chrome network panel to throttle to "Regular 3G"
* from both a clean cache and a primed cache:
* make sure that the total time to render the page
is about on par with requireJS
first change: load webpack chunks from CDN
fixes: CNVS-32261
test plan:
* run `npm run webpack-production`
* check your page, it should load js files and chunks
from the same hostname the page is served from.
* now set a host: in config/canvas_cdn.yml
(for testing locally, I just set it to http://127.0.0.1:3000,
* restart rails and reload the page, now the scripts and
chucks should come from that new hostname
second change:include fingerprints in webpack bundle and chunk filenames
closes: CNVS-28628
with this change we don't need to run `gulp rev`
after running webpack and we can load both the bundle
and chunk files safely from the cdn, since they will
have content-based fingerprints so we can tell
browsers to cache them forever. (we set those
http caching headers in lib/canvas/cdn/s3_uploader.rb:53)
test plan:
* for both dev and production
* run `npm run webpack` (or `npm run wepack-production`)
* with a cdn configured in canvas_cdn.yml, run:
RAILS_ENV=<dev or prod> bundle exec rake canvas:cdn:upload_to_s3
* check to make sure that the page loads the webpack js,
that there are no errors, and it all came from the cdn
third change: properly handle moment locale & timezone in webpack
test plan:
(see application_helper_spec.rb)
* set a non-default user timezone, context timezone
and locale
* dates should show up in your timezone and and
the date helper strings should be in your language
better handling of moment custom locales
closes: CNVS-33811
since we now have hatian and maori, we need to do this in
a way that is not just a one-off for maori
test plan:
* set your locale to maori
* in webpack & requireJS make sure dates show up right
Change-Id: I34dbff7d46a1047f9b459d5e1c0d141f435d42fb
Reviewed-on: https://gerrit.instructure.com/95737
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Tested-by: Jenkins
QA-Review: Benjamin Christian Nelson <bcnelson@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
Test Plan:
1. Register an LTI tool with a course_assignments_menu placement
2. Navigate to course assignments page as a teacher or admin
3. Click gear icon next to new group/assignment buttons at top
* Observe that LTI tool from step 1) appears as an entry here
4. Click the LTI tool entry to launch the LTI
* Observe that a dialog opens with the LTI launched
Use config file from spec/fixtures/lti/config.course_assignments_menu.xml
for registering fake tool for step 1 if you don't have a real tool with
the placement.
Change-Id: Ia638f28b69ecb2821f0d8cd8f4607ef74ee6fe18
fixes: SIS-2627
Reviewed-on: https://gerrit.instructure.com/97295
Tested-by: Jenkins
Reviewed-by: Brad Humphrey <brad@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Brad Humphrey <brad@instructure.com>
fixes SD-1724
in previous refactorings, plugin and ember js specs stopped running, and
regular specs started running twice
test plan:
1. confirm that ember specs run and pass now (110 of them)
2. confirm that more regular specs run than before (cuz plugins)
3. confirm that the regular specs don't run twice (unless it does the
retry thing)
4. `sudo -u clay test it every which way`
Change-Id: I24ac56b9d3082e25d15f06193c9a9e5c4313b7a7
Reviewed-on: https://gerrit.instructure.com/94305
Tested-by: Jenkins
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
closes: CNVS-31787
the only things left in bower are things that
are just not avalable on npm because they are so old.
we'll have to continue using the bower versions of them,
but it's ok since they are mostly old ember stuff
that will be ripped out when we finish our react screenreader gradebook
also:
remove some ember stuff that wasn't being used anymore.
nothing was using this stuff
test plan:
this really does touch a lot of stuff. some things
to check out specifically in the prod/optimized requireJS build:
(load the page, click around to make sure things work)
the screenreader gradebook
client_apps:
quiz statistics
quiz event logging
creating a new student group
calendar, try all the views (month/agenda/etc)
gradebook 2
turn on the new course/user search feature for your account
and go to accounts/x and search for a user/course
the new react gradebook
use tinymce on a page, make sure that both the service
and local version of it work
Change-Id: I4322a154d289760ab51b92e34dd7fac808b41ba8
Reviewed-on: https://gerrit.instructure.com/93102
Tested-by: Jenkins
QA-Review: Benjamin Christian Nelson <bcnelson@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
When using webpack, we pack up everything outside of karma and
assuming you've set webpack to generate source maps it doesn't actually
use them. This makes it so that it does use them so output can
be much better.
Test Plan:
- Have your environment set up to use webpack
- Change webpack.test.config.babel.js:23 to be:
testWebpackConfig.devtool = 'inline-source-map';
- Comment out lines 64-68 of the same file
- Run npm run webpack-test-watch to bundle the
tests
- Run the specs (doc/testing_javascript.md)
- Make a test fail... you should see a mapping
from bundled test file to the actual file.
Change-Id: I650fe995d6aa595d89da5ae614d5407a699e75ec
Reviewed-on: https://gerrit.instructure.com/89822
Tested-by: Jenkins
Reviewed-by: Joel Hough <joel@instructure.com>
Product-Review: Clay Diffrient <cdiffrient@instructure.com>
QA-Review: Clay Diffrient <cdiffrient@instructure.com>
After the karma upgrade some things changed around that essentially
made it not work at all. This makes it so that it works again.
In testing when JS_SPEC_MATCHER was set to **/*BreadcrumbsSpec it matched
properly, but the tests failed for some reason. Other tests seemed to
pass as expected. I'm pretty sure it has something to dow with requirejs
not loading something properly, but it's pretty isolated..
Change-Id: I2720ba97252ee4d3c18f350c22a02aa58df93be3
Reviewed-on: https://gerrit.instructure.com/87681
Tested-by: Jenkins
Reviewed-by: Jeremy Neander <jneander@instructure.com>
Reviewed-by: Derek Bender <djbender@instructure.com>
Product-Review: Clay Diffrient <cdiffrient@instructure.com>
QA-Review: Clay Diffrient <cdiffrient@instructure.com>
Fixes CNVS-30301
Test Plan:
- Running the js tests locally should generate
a folder called coverage-js with an index.html
file that has the coverage information
Change-Id: Ib57b40c60791324d0a1eafab4c541957a2c2e7e7
Reviewed-on: https://gerrit.instructure.com/84839
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
Tested-by: Jenkins
Product-Review: Steven Burnett <sburnett@instructure.com>
QA-Review: Steven Burnett <sburnett@instructure.com>
this was a blocker for upgrading to node 6 since
karma 0.x has a strict node version requirement
of <=4, so it would not work on node 6 (although,
ironically, if you forced it it would still work)
closes: CNVS-30308
test plan:
* run `npm install && bundle exec rake js:test`
* it should work
* the jenkins builds should all work
Change-Id: Ifd9ae12347d7901cf2bafee110230699987b2511
Reviewed-on: https://gerrit.instructure.com/84590
Tested-by: Jenkins
Reviewed-by: Matthew Sessions <msessions@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
refs SD-1060
if a jenkins node is overloaded or has too few cores, tests can abort
before starting. sometimes it takes more than 10 seconds for requirejs
to load :allthethings: 😭
Change-Id: I72f3c39abb65a06524bbb981a8fdd8a7cbbac568
Reviewed-on: https://gerrit.instructure.com/81659
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Tested-by: Jenkins
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
refs SD-743
fixes CNVS-26721
This adds a qunit assertion helper that wraps the aXe library. Rules can
be ignored by passing an array of rules in the options argument to the
helper.
e.g.
`assertions.isAccessible $html, done, { ignores: 'aria-valid-attr-value'}`
Test plan:
Undo the changes that I made to the DashboardCard.jsx component.
You should get a warning about invalid aria attributes because the
aria-controls attribute is referring to an element that doesn't exist.
To fix this, I modified the component to hide/show the color picker so that
the aria attribute value is valid.
If you add the ignores option as described above, the test should pass
without my changes.
To verify the dashboard card color picker changes:
- Verify that you can click or use the ENTER key on a dashboard card
cog button to bring up the color picker
- Verify that you can select a color and apply it to the card.
- Verify that you can click outside the color picker to close it
- Verify that you can hit the ESC key to close the color picker
- When the color picker is closed, focus should return to the the cog
button trigger
- After selecting a color you should be able to open the color picker again
and select a different color
The color picker in the Calendar should be regression tested as well.
Change-Id: I5d5bfdaf39df1e0cb8776144771baeb1ed31ff2a
Reviewed-on: https://gerrit.instructure.com/70638
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Product-Review: Colleen Palmer <colleen@instructure.com>
QA-Review: Myller de Araujo <myller@instructure.com>
Tested-by: Jenkins
closes CNVS-26213
Allow using a config file rather than an env var
for turning on web pack.
TEST PLAN:
1) set USE_WEBPACK env var to nothing
2) touch config/WEBPACK
3) web pack should still be enabled
4) rm config/WEBPACK
5) restart server
6) canvas should use require-js bundles again
Change-Id: Ie733b66326482341c2371fddefe17c1cfa3006b3
Reviewed-on: https://gerrit.instructure.com/69739
Tested-by: Jenkins
Reviewed-by: Ryan Shaw <ryan@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
closes CNVS-24966
change js specs to work with web pack.
update some dependency references, make some aliases
for external dependencies to get the right version,
and clean up a bunch of leaky state.
TEST PLAN:
js tests should pass in web pack _and_ requires
Change-Id: If37fbce93e7e67021d90bacb470ffc4f1b17402d
Reviewed-on: https://gerrit.instructure.com/66309
Tested-by: Jenkins
Reviewed-by: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
the big change here is that now you have to call server.respond() again
if part of the response triggers more ajax actions. this is actually
a nice change, which gives us more flexibility over how these are
handled.
fixes CNVS-24661
test plan: js specs should still pass
Change-Id: I0eaf27159d2990b51873f190cccd14782d6d65ee
Reviewed-on: https://gerrit.instructure.com/66103
Reviewed-by: Ethan Vizitei <evizitei@instructure.com>
Tested-by: Jenkins
Product-Review: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
closes CNVS-24124
makes working with web pack possible in canvas
instead of require-js. See doc/working_with_webpack.md
for instructions.
TEST PLAN:
Nothing should change in non-webpack'd behavior
Things should mostly work when you use the
USE_WEBPACK environment variable, but make sure to document
and ticket things that don't
Change-Id: I493a259a609e9e183950bc57aa5876df70108547
Reviewed-on: https://gerrit.instructure.com/64386
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
we included this to help handle a js action queuing multiple ajax calls,
but it works better to just use fake timers to manage that interaction.
fixes CNVS-24582
test plan:
- js tests should still pass
Change-Id: I01cd5ad37e003ddf06956caad3c69a9e58cabab0
Reviewed-on: https://gerrit.instructure.com/65845
Reviewed-by: Ethan Vizitei <evizitei@instructure.com>
Tested-by: Jenkins
Product-Review: Simon Williams <simon@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
everyone was getting build errors when they
were npm install'ing. it was because karma 0.10
depended on an out-of-date version of chokiadr
that does not compile against node 0.12
I also indicated that canvas is licenced agpl 3
so that you wouldn't always see an npm warning
about not having one.
also, let karma serve our css files
so if any javascript references them in our quit
tests, we don't see 404 warnings
Change-Id: Iaa0377bc87b8f7ec8726d6cb82c0f8a103134b56
Reviewed-on: https://gerrit.instructure.com/58584
Tested-by: Jenkins
Reviewed-by: Mike Nomitch <mnomitch@instructure.com>
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
This patch handles a couple of things:
- `require` calls should not be used at the start of test files,
but they were. This switches them to `define`.
- There were a handful of tests that were not fulfilling initialized
promises, which led to the test suite hanging.
- There was a failure that popped up sometimes because `helpDialog`
was not cleaning up after itself. This adds a protection to
make sure that the instance is initialized before it is used.
Change-Id: Ie57f5ee6d45216f0d4071d34cc476201c3b7c9f6
Reviewed-on: https://gerrit.instructure.com/48447
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Adam Stone <astone@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
fixes CNVS-9759
test plan:
* navigate to the user settings page, and click your
avatar;
* verify that you can click the "select a photo" view to
pick an image, or that you can drag a photo directly
onto it;
* crop the picture using the crop tool and press the
"select image" button;
* verify that the button becomes disabled and that the
dialog then closes and your new avatar is displayed.
* refresh the page and make sure the new avatar sticks.
Change-Id: Ic33cc89e66ce3bf2bed834f2aac2f37029008ec1
Reviewed-on: https://gerrit.instructure.com/26890
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Steven Shepherd <sshepherd@instructure.com>
Reviewed-by: Jon Willesen <jonw@instructure.com>
Reviewed-by: Braden Anderson <banderson@instructure.com>
Product-Review: Jon Willesen <jonw@instructure.com>
- js:generate_runner now generates common files to be used by different test runners
- js spec file order now shuffled to better expose dependencies
- fakeENV now returns two methods: setup and teardown
- stock tinymce 3 files are now wrapped for AMD
test plan:
- tinymce should work the same
- js:test rake task should run tests
- js:build task should work as normal (using new location of r.js)
- test results should successfully send to firework
Change-Id: Ic09647f55dae57130fa0fe3d6a9168d2b67b89a2
Reviewed-on: https://gerrit.instructure.com/29297
QA-Review: Shawn Meredith <shawn@instructure.com>
Tested-by: Shawn Meredith <shawn@instructure.com>
Tested-by: Aaron Shafovaloff <ashafovaloff@instructure.com>
Reviewed-by: Aaron Shafovaloff <ashafovaloff@instructure.com>
Product-Review: Aaron Shafovaloff <ashafovaloff@instructure.com>
QA-Review: Aaron Shafovaloff <ashafovaloff@instructure.com>
Ryan Shaw