Testing Team Meeting – Jan 14 2015

  • 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

Testing Team Meeting – Oct 08 2014

  • 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

Testing Team Meeting – Aug 13 2014

  • QUnit
  • 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

Testing Team Meeting – Jun 18 2014

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

Testing Team Meeting – Jun 04 2014

  • 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

Testing Team Meeting – Mar 26 2014

  • 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

Testing Team Meeting – Feb 13 2014

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?