• QUnit
  • Leo prototyping to test ES6 features via Goiabada: https://github.com/leobalter/goiabada
  • babel works well for transpiling ES6, but to output browser-compatible code we need another step; browserify doesn’t support UMD, still need to solve that
  • alternative: disable babel’s es6.modules transform, then use esperanto to transform to UMD
  • Scott to put together a test
• TestSwarm
  • Moved to new server, seems to work fine
• browserstack-runner
  • Enabled browserstack-runner for Travis, including PRs, for QUnit repo
  • Will do the same for Globalize once requirejs load issues are resolved
  • jQuery UI takes 5+ minutes to run everything, times out before finishing

• QUnit
  • Landed double export for node, to make require(“qunit”).QUnit work on all “CommonJS”-like envs
  • Still need to fix a 1.16 regression to finish 1.17. James to tackle that.
  • Moved last qunit-plugin repos of the jQuery GitHub organization
  • Let’s add test/reporter-html to grunt
• TestSwarm
  • Updated the readme to indicate the kind-of abandoned project status
• Testing Infrastructure
  • Still trying to get browserstack-runner working on Travis. Issues are on their end, testing every now and then, making progress.
  • Got Globalize tests to pass in browserstack-runner locally. Sent PR to run on Travis, waiting for issues to get resolved before landing it.
• CSS Testing (mostly performance testing; for Chassis, UI, Mobile)
  • Alex talked to Kristofer, will discuss next steps soon
  • Will start implementing it in Chassis
• Site spider
  • Alex rewrote it recently
  • Publishing standalone module for Arthur to use it with gulp and h5bp
• jshint vs eslint
  • Both active, neither uses esprima

• QUnit
  • Released 1.16.0
  • Fixing regressions
  • Discussing QUnit.test(name) as an alternative to QUnit.skip(name)
• Testing Infrastructure
  • Still trying to get browserstack-runner working on Travis
  • Also get Globalize unit tests to pass on browserstack-runner
• CSS Testing
  • Alex to ping Kristofer (Topcoat)

• QUnit
  • Working towards 1.16
  • Finishing lots of stuff
  • Updated commitplease, can now specify components
    • Test vs Tests, is QUnit.test part of Core?
  • Will not rename, but drop config.before/afterEach, revisit along with nested suites
  • Jörn to review and merge Mislav’s two PRs
• TestSwarm
  • n/a
• Testing Infrastructure
  • Implemented worker reuse in browserstack-runner, merged and published, will integrate QUnit with Travis
  • Scott created separate accounts for QUnit and Sizzle (if they want to use the same obfuscation approach with Karma and PR tests)

• QUnit
  • Working towards 1.16
  • Working on assertions after done() failing
• Testing Infrastructure
  • Implemented worker reuse in browserstack-runner, waiting for them to approve the PR.
  • Hoping for Travis to implement opt-in for secure env vars in PRs

• QUnit
  • Released 1.15 on Friday, need to update jQuery projects to use that
    • jQuery Core is messy, was working before (with 1.15-pre), now has lots of failing tests
  • Timo asking karma-qunit team to loosen their peerDependency on QUnit, currently strictly on 1.14, which is useless
    • PR to update to 1.15
    • PR to require >=1.14 range
  • 1.15 removes undocumented QUnit.addEvent, need to update plugins that make use of that, for example qunit-assert-html
    • Removed methods from the QUnit object: addEvent(), id(), addClass(), removeClass(), hasClass()
  • Leo experimenting with console reporter
    • tap is too verbose for humans, optimized for machine
    • Maybe use a module that eats tap and outputs userfriendly logs
• TestSwarm
  • No progress on rerun handling, #217
  • TestSwarm seems to be running fine, low BrowserStack worker loss rate according to reports in Splunk
• Testing Infrastructure
  • Michał is working with BrowserStack people, asking for new releases in API and dealing with their failed experiment on real mobile devices

link QUnit

• Leo working on assert instance, #588
• Progress on supporting other envs, waiting for some code improvements to land #540
• Landed API updates with redirects, jquery/api.qunitjs.com#49
• Working on maxDepth config for QUnit.dump (formerly QUnit.jsDump)
• James to work on assert.throws related PR and issues

link TestSwarm

• Improving rerun handling would be a big improvement for our own testing, #217
• Discussed with Timo previously, more effort than expected.

link Testing Infrastructure

• n/a

• QUnit
  • Leo started on assert instance, #588
  • Ongoing discussion about supporting non-browser envs, #540, running QUnit tests in CLI with node might address some of the related issues and would have a more direct value
    • Leo to look into after working on reporter interface
  • API updates with redirects are ready to land, jquery/api.qunitjs.com#49
• TestSwarm
  • Improving rerun handling would be a big improvement for our own testing, #217
• Testing Infrastructure
  • n/a

• QUnit
  • James put together a proposal for a set of events for a reporter interface
• TestSwarm
  • New jobs for Core and QUnit (still in progress), for weekly runs with old/slow browsers
• Testing Infrastructure
  • browserstack-runner is now working pretty well, hoping for better logging, via #51

Location: jQuery Conference San Diego

Attending: James, Timo, Leo, Jörn

• reporter interface that we can share with other testing tools
  • to make it easy to integrate into karma, browserstack-runner or grunt plugins
  • needs a data format ala JUnit XML (maybe ala tap?), that is flexible enough to support QUnit and others
  • reporters should be built on top of this format: console, html etc.
  • need to do research for this - how do other test frameworks and their integrators currently handle this? What are the differences?
• assertions cleanup
  • what do we really need to keep?
  • make equal/notEqual() strict and drop strictEqual/notStrictEqual
  • deprecate/remove ok()
    • need to research how ok() is used, and document what to do instead
    • like ok(array.indexOf > -1) -> notEqual(array.indexOf, -1)
• make it reasonable to compose assertions
  • at least expose the traversal of QUnit.equiv
  • maybe expose an API for custom assertions that fixes stack traces when delegating to other assertions?
  • or try to have the assertion wrapper/constructor keep track, so that it doesn't matter on what level you call assertions, it'll unwrap correctly
  • or try and see what happens if we simplify the stack trace handling - a few more lines might be worth removing the complexity
• async tests!
  • references: mocha, nodeunit
  • force calling done like nodeunit? make that configurable?
  • grunt style async() method that returns a callback which you run when done?