Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make CI run browser tests #2231

Merged
merged 4 commits into from May 23, 2016
Merged

Make CI run browser tests #2231

merged 4 commits into from May 23, 2016

Conversation

dasilvacontin
Copy link
Contributor

Resolves #2079 – still WIP.

"Difficulties" found so far:

  • zuul comes with Mocha bundled (they actually have our bundle file in their source πŸ‘Œ ) – this makes it hard to make some tests work, as they rely on the Mocha code being tested to be also the code that is running the tests. Might be worth taking a look at using Karma-PhantomJS framework-less (without having Mocha bundled).
  • zuul didn't accept arrays for the included / excluded browserify options, had to fix and fire a PR: Support Arrays in browserify confΒ defunctzombie/zuul#280.
  • a lot of the tests are written in a way that you have to execute Mocha for each file (hence the super large Makefile with lots of different test-xxx). Together with the fact that quite a few tests can only work in node (using fs, http.createServer and such) makes that the subset of tests that can be run in the browser is not as big as one would hope. Rewriting some of the tests + adding new ones would be ideal, but not sure it's super worth considering that we are looking forward to the Mocha's rewrite. Still, those tests could likely be ported to the rewrite, not so bad I guess...
  • I might need admin permissions over the org/repo to generate and encrypt sauce labs credentials – not sure yet, but it wouldn't hurt having them I guess. /cc @boneskull

Feedback is welcome – looking forward to getting this done and rocking the of the issues/PRs!

@danielstjules
Copy link
Contributor

danielstjules commented Apr 28, 2016

Have you thought of just using phantomjs (w/ mochify) or nightmare for browser tests as discussed here #2079 (comment) ?

I'd probably not recommend using zuul w/ sauce labs for all our browser tests as it's a flakey setup, though it works great locally. There's just something about running it on Travis. :) I use zuul for https://github.com/zendesk/cross-storage The builds end up experiencing frequent connection errors (between travis, localtunnel or saucelabs, etc) Here's an example: https://travis-ci.org/zendesk/cross-storage/builds/123155396 Looking at the build history you can see that they eventually pass, it just often takes a restart or two.

Edit: Though this could have been resolved in newer releases :)

@dasilvacontin
Copy link
Contributor Author

Edit: Though this could have been resolved in newer releases :)

What are you referring to?

I'm gonna give PhantomJS and other solutions a go – thanks for sharing!

@danielstjules
Copy link
Contributor

Oh, just meant that maybe stability improved in a more recent release, though I'm not sure.

@dasilvacontin
Copy link
Contributor Author

dasilvacontin commented Apr 29, 2016

Going good so far using mocha-phantomjs. I'm able to test the source using the source itself as the test framework.

@dasilvacontin
Copy link
Contributor Author

Status update: I've been sick. I'm feeling better now – looking forward to make progress on the PR.

@@ -1,5 +1,5 @@
exports.isatty = function isatty() {
return true;
return false;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

self-note: look into why were we reporting tty as true in the browser

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's been there since @tj first committed the file. Not sure why yet.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ooh, hmm, missed this. it shouldn't change unless we have a good reason.

@ScottFreeCode
Copy link
Contributor

For what it's worth, if the idea of using Karma in order to use a git checkout of Mocha instead of a published/bundled version is still being kicked around, Karma + Karma's Mocha runner seems to work with a local checkout of Mocha if you add Mocha's folder to the NODE_PATH environment variable (so it gets picked up the same way it would if it were in node_modules). And by "work" I mean it will at least try to run and presumably should work just as well as using Mocha with Karma for any other project, not that I actually have got to the point where tests are passing instead of having weird failures like Karma restarting the browser three times for no apparent reason. ;^) Karma's also supposed to a Sauce Labs runner that I would hope can run IE 8, since that's probably the browser that most needs testing against beyond picking any modern browser just to make sure some Node library doesn't break browsers altogether; I haven't even started to try that, though.

The other test runner I've heard of is Testling, which I'm pretty sure I've heard of being used with Mocha, but I haven't yet looked into whether that allows you to provide your own copy of the test library without having to write your own adapter with which to use it.

@ScottFreeCode
Copy link
Contributor

Addendum: You also have to build an up-to-date mocha.js file to use Karma's Mocha plugin with NODE_PATH including Mocha's folder. That poses a certain amount of potential conflict with the "don't update mocha.js till a release" policy... although not much -- CI isn't getting checked back into Git, so it shouldn't matter if it updates the build in order to run tests, whereas local testing... you'd just have to be sure to tell Git to discard the changes to mocha.js I guess. Well, that's that for what it's worth; I'll report back if I discover anything else worthy of note in the process of actually getting to where tests pass.

@ScottFreeCode
Copy link
Contributor

So, I can't seem to get bundling the test files (and by extension their dependencies) like the phantomjs bundle to work with Karma, but I did figure out that it works fine if I give Karma the list of test files instead, as long as:

  1. I also give it the files for assertion libraries like "should" and any similar dependencies.
  2. The test doesn't have any requires that can't be satisfied by the browser files for such libraries.

@boneskull
Copy link
Member

it appears we'll want to run IE and phantomjs (pre 2.0), so I think the most direct route to that might be to just pick up karma and eschew mocha-phantomjs.

@boneskull
Copy link
Member

where are the builds?

@boneskull
Copy link
Member

I have a feeling I screwed something up w/ travis but I have no idea what that could be.

throw new Error(err);
}
// I'm unsure what this one is for, but whatever.
exec('npm install --global npm', function (err) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

npm v1.x can't upgrade directly to v3.x, so we first upgrade to v2, and then to v3.

Why was the script rewritten? With what purpose? The only behavioural change I see is the if condition, and that could have been easily changed in the bash script afaik.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

npm v1.x can't upgrade directly to v3.x, so we first upgrade to v2, and then to v3.

we don't need to actually upgrade to v3? so, we can skip that.

the shell script won't run on windows. this is premature optimization, because I know that we'll need to run IE, and I don't want to have anything in here that isn't portable. it also opens us up to running unit tests on diff platforms eventually.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we don't need to actually upgrade to v3? so, we can skip that.

But maybe it wouldn't be a bad idea to test if dependencies install correctly while using the current version of npm.

the shell script won't run on windows. this is premature optimization, because I know that we'll need to run IE, and I don't want to have anything in here that isn't portable. it also opens us up to running unit tests on diff platforms eventually.

Good call.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But maybe it wouldn't be a bad idea to test if dependencies install correctly while using the current version of npm.

Nvm, we are already doing that when testing on newer Node versions.

@dasilvacontin
Copy link
Contributor Author

dasilvacontin commented May 13, 2016

@boneskull what builds? afaik the package.json and/or Makefile hasn't been changed so that phantom.js is run on CI. I don't see any code related to spinning up karma either.

If you mean Travis builds, I can see them now, but maybe you've experienced some kind of delay. (?)

@dasilvacontin
Copy link
Contributor Author

I just saw from the other PR that you meant Travis. πŸ™ˆ

@boneskull
Copy link
Member

yes, there was a significant delay. anyway, the phantomjs version is failing to install on 0.8 for some reason. but the older ones (1.9.7.x) fail to install on newer versions of node, so ugh.

@ScottFreeCode
Copy link
Contributor

Something that crossed my mind: Will the mocha.js need to have its timestamp tweaked so that make will be able to tell whether to update it for the tests, e.g. like https://gist.github.com/davidwindell/fbfef588c6295666c6a1 or maybe https://gist.github.com/jeffery/1115504 ?

@ScottFreeCode ScottFreeCode force-pushed the add-browser-to-CI branch 2 times, most recently from a895e63 to 907011e Compare May 19, 2016 22:26
@ScottFreeCode
Copy link
Contributor

ScottFreeCode commented May 19, 2016

Check it out! The tests are finding the actual IE8 incompatibilities now (and otherwise passing*)!

*Well, I've still got to figure out what to do about PhantomJS; latest doesn't work on Node 0.8, but we got a failure [seemingly unrelated to any change or code on our end] downloading 1.9.8 recently.

@ScottFreeCode
Copy link
Contributor

ScottFreeCode commented May 20, 2016

Some additional comments:

  • I've been testing with IE11 with Karma's HTML tweaked to trigger IE8 compatibility mode (not sure if that's how I ought to be doing it, but it works for most things...). I do not get the failure on the test for length that cannot be coerced to number. Is it likely to be an issue that exists in real IE8 but not IE8 compatibility mode? (EDIT: could it be the use of toString as the property name? Obviously I can't easily check except by pushing and seeing if a different property name fixes it.)
  • Looks like a lot of these are the toISOString issue (cf Fix missing methods/globals in IE7, IE8 environmentsΒ #2259). If I run the interface browser tests a lot of them are indexOf. (Note to self: look at which object/prototype is missing indexOf and whether it's being used inside Mocha itself or just in the test code.) (EDIT: These are all handled now, at least assuming my IE8 test for the prototypeless object is valid.)
  • After we fix the ones we can fix quickly, do we want to disable the difficult IE8-failing tests (say, using reverse grep?) in the IE8 test run only, in order to go ahead and start getting other things tested and merged and be able to come back and fix those tests for IE8 in due time? (EDIT: there's only one left, the length thing.)

@ScottFreeCode
Copy link
Contributor

ScottFreeCode commented May 20, 2016

  • Do we want to remove [revert] any of the earlier changes that were aimed at mocha-phantomjs (e.g. to test/browser/...)?

@ScottFreeCode ScottFreeCode force-pushed the add-browser-to-CI branch 3 times, most recently from 929bc2e to ff3664a Compare May 20, 2016 22:15
@ScottFreeCode ScottFreeCode force-pushed the add-browser-to-CI branch 2 times, most recently from d24b6e8 to f9a727e Compare May 20, 2016 22:43
@ScottFreeCode
Copy link
Contributor

@dasilvacontin, @boneskull, I think I've got everything working! Take a look and let me know if there are any issues, or if there's anything else we need to do before merging this. (Thanks!)

@ScottFreeCode
Copy link
Contributor

ScottFreeCode commented May 21, 2016

Attempted to squash this a bit... David's contributions are a bit scarce between the fact that some of them ended up not being used and the fact that his improvements to the makefile were absorbed into Christopher's; and I'm ambivalent about whether that one commit that changed return ' "dave"'; to get "dave" from the array being mapped should be absorbed into the previous squash (what I've got here), or put in its own commit for obviousness, or just dropped... But it'll do if it looks good to everyone else. I've saved the original line of commits in the branch add-browser-to-CI-detailed if anyone wants to compare (although I don't know that GitHub's comparison features are going to give meaningful info on them, since they amount to the same net changes but by entirely unrelated commit history) or if we need to roll back the squashing and try again.

@boneskull
Copy link
Member

restarting some failed jobs due to failed d/l of phantomjs prebuilt binary. once these pass, I think we're good.

@boneskull
Copy link
Member

(thereafter I'm going to squash this in at least a couple places)

@@ -266,7 +267,8 @@
"node": ">= 0.8.x"
},
"scripts": {
"test": "make test-all"
"preinstall": "node scripts/fake-karma-mocha-peer-dep.js",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

karma-mocha has a peer dep on mocha, which is a problem. we want it to use, well, this mocha, so we just symlink node_modules/mocha to the root.

this is causing a problem atm because we're not publishing the scripts dir. I'll figure out a solution; it doesn't need to run anyway unless you're running npm install from a working copy

- ⬆️ browserify@13.0.0

  Some fixes that we didn't have were required.

- πŸ› Fix browser not being able to require describe/it

  `support/browser-entry.js` was removing the listener that is in charge
  of keeping `Mocha.describe/it/suite` etc up-to-date.

  That listener is now added everytime a `ui` is set up.

- Correct isatty for browser
- '0.8'
matrix:
include:
- node_js: '6'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we could also add an osx target here, if anyone cares.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth trying, but probably best done after we get the basic browser testing merged.


if (process.env.TRAVIS_NODE_VERSION === '0.8') {
var exec = require('child_process').exec;
// ensure *dependencies* are installed using provided npm
Copy link
Member

@boneskull boneskull May 21, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(because if they don't, then mocha won't install on vanilla 0.8)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gonna amend this to can be installed

boneskull and others added 3 commits May 22, 2016 21:59
- add sauce connect
- prepare to use karma on saucelabs; fix potential windows problems
- rewrite `scripts/ensure-compatible-npm.sh` in JS
- detect travis node 0.8 env; just upgrade if found
- symlink `mocha` to itself for `karma-mocha`
- if explicit `--production` flag is present, skip this
- don't know how to skip this part if `mocha` is a devDep of some other package
- use phantomjs@1.9.19; don't try to install npm@3
- browser tests with karma & phantom
- move `support/browser-entry.js` to `browser-entry.js` to keep paths sane
- `karma.conf.js` loads data out of `.karma.conf.js`
  - we have a "main" browser suite
    - then we have suites for each interface
    - each suite is a single run of Karma
    - each suite is executed by the `Makefile`
  - build `./mocha.js` upon test execution for `karma-mocha` to use
  - bonus: 3rd-party browserification should theoretically now be possible as per the `./index.js` entry in `package.json`'s `browser` field
  - add dev deps for karma
  - test changes:
    - split `lookupFiles` test into its own file so we can ignore it in Karma
    - fix broken `test/acceptance/throw.js` for browser
    - fix `test/acceptance/utils.js`'s `type` tests for PhantomJS
- try to reduce build matrix
- fix missing targets
- fix infinite loop in Makefile
- downgrade phantomjs to 1.9.8
- remove some cruft from karma config; try to add sauce labs
- try again w/ the saucelabs
- typo
- remove karma-source-map-support as it's a no-go on IE8
- Require up-to-date mocha.js for any browser tests
- Make CI rebuild mocha.js.  Make won't rebuild when just checked out by CI because timestamps on source and mocha.js are the same.  We could use a script to set the timestamps to the commit time, but it still wouldn't work if mocha.js were committed along with other changes that hadn't been built into it. Which shouldn't happen anyway -- but then again, the point of CI is to see what commits change, it's usually going to need to rebuild mocha.js if it's working right, so it's not going to hurt much to rebuild it every time even on the few times it doesn't need to.
- Avoid `Array.prototype.map` in test
- Workaround for missing `Object.create`
- Use a shim for `Date.prototype.toISOString`
- Use simple number math instead of array indexing for interface tests
- Use `expect` instead of `should`
- Avoid builtin function in stringify test (A quick check revealed that stringify does not treat toString specially anyway, and IE8 ignores the toString assigned to the object, so use a different property name)
- Use `karma-expect` for automatic browser tests
- Remove `karma-should`
- add note about exporting `global` in `browser-entry.js`
- remove too-short timeout for "throw" unit tests (because SauceLabs)
- revert modification to `isatty()` function of `lib/browser/tty.js`
- switch reporter to `karma-spec-reporter`
- use custom `karma-no-mocha` package
- fixtures in `test/browser-fixtures/`
- use single `karma.conf.js`
@boneskull
Copy link
Member

@mochajs/mocha unless someone has an objection, I'll likely merge this today or tomorrow

@boneskull boneskull merged commit c04c1d7 into master May 23, 2016
entertainyou added a commit to entertainyou/mocha that referenced this pull request May 23, 2016
to-iso-string is used in lib/utils.js since mochajs#2231

Fixes mochajs#2272
@ScottFreeCode
Copy link
Contributor

Sorry about the to-iso-string mishap; I added it where the other new dependencies were without thinking about the fact that it's used in the framework code itself rather than just the tests.

@dasilvacontin
Copy link
Contributor Author

@ScottFreeCode No worries. Sorry for not noticing that during code review ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add browser test suite to CI
4 participants