Skip to content

Loading…

Implement multi-value support for urlConfig UI #385

Closed
dmethvin opened this Issue · 7 comments

5 participants

@dmethvin
jQuery Foundation member

For testing the jquery-migrate plugin we wanted this:

At the moment it's implemented by the jquery-migrate unit tests injecting the markup into the QUnit toolbar after it initializes.

Is there a clean way to do this as a QUnit plugin, or would it perhaps make sense to add to QUnit itself?

@Krinkle
jQuery Foundation member

Makes sense to support in QUnit itself. We can support it by allowing array/object values in urlConfig in addition to strings.

Something like this:

// Checkboxes (current format, will continue to be supported)

urlConfig.push({
  id: 'foo',
  label: 'Enable foo',
  tooltip: '...'
});


// Checkboxes (new format)

urlConfig.push({
  id: 'foo',
  value: 'bar',
  label: 'Enable foo',
  tooltip: '...'
});


// Select (new format)

urlConfig.push({
  id: 'foo',
  value: ['bar', 'baz', 'quux'],
  label: 'Foo',
  tooltip: '...'
});


// Select with custom display text (new format)

urlConfig.push({
  id: 'foo',
  value: { bar: 'Barbara', baz: 'Baz' , quux: 'Quuxification' },
  label: 'Foo',
  tooltip: '...'
});
@JamesMGreene
jQuery Foundation member

Both the need and @Krinkle's proposed usage examples make sense to me.

@gibson042 gibson042 added a commit to gibson042/qunit that referenced this issue
@gibson042 gibson042 Issue #385: urlConfig select-one lists 9dea61b
@gibson042 gibson042 added a commit to gibson042/qunit that referenced this issue
@gibson042 gibson042 Issue #385: urlConfig select-one lists c7c466f
@gibson042 gibson042 referenced this issue in jquery/api.qunitjs.com
Closed

Config: Document urlConfig options #42

@leobalter
jQuery Foundation member

I am sorry to disagree but I don't see this as a good choice in terms of CI. If it's needed to test something on multiple versions of jQuery (or any other thing) I would create an alternative routine to run the tests for each version, without a request for a human choice. It would take longer for testing everything, but it would make more sense for automated tests.

In a step by step example:

  • load jQuery 1.6.4
  • run the tests
  • load jQuery 1.7.2 (replacing the last loaded jQuery)
  • run the tests again
  • load jQuery 1.8.3 (replacing the last loaded jQuery)
  • ...

The other way I see to do it and separate the html calling (being hard coded wouldn't be nice for maintenance). Doing this I would use the suggested select in QUnit toolbar to only change the link to each of the htmls.

@scottgonzalez
jQuery Foundation member

@leobalter All of that logic already exists in projects like jQuery UI and jQuery Migrate. This is just exposing the underlying functionality through the UI.

@leobalter
jQuery Foundation member

@scottgonzalez oh, regarding this I don't have anything else to complain about this. Sometimes it looks uncertainly as I'm not up to date on all of the projects. Thanks for clarifying it.

@dmethvin
jQuery Foundation member

@leobalter We already have the ability to automate the multi-version process with TestSwarm, but when testing a plugin that is supposed to work with multiple versions of a dependent file it's really handy to have the ability to do it from a manual run in the browser.

@Krinkle
jQuery Foundation member

Besides, one doesn't exclude the other. One can still run multiple tests in automated CI (the values are read from the query string, we already do this at jQuery for jQuery UI in our Jenkins/TestSwarm set up). It merely serves as a de-duplication technique while at the same time allowing easy navigation from one to the other.

So instead of queuing something like /test/index-jq172.html and /test/index-jq183.html in your CI flow, you'd queue /test/index.html?jq=1.7.2 and /test/index.html?jq=1.8.3.

It has a minor advantage by not duplicating the rest of the test suite html, and discoverability for humans during local development (dropdown menu instead of navigating to the parent directory, it also transfers any other query parameters you may have set).

The only downside is that this technique requires one to do the loading in javascript (instead of an actual <script> tag). However, considering that this feature is completely opt-in, that shouldn't be a problem. If you don't want to or are in a restricted situation where this isn't possible, simply don't use it :)

@jzaefferer jzaefferer added a commit to jquery/api.qunitjs.com that referenced this issue
@gibson042 gibson042 Config: Document urlConfig options 733c8b4
@jzaefferer jzaefferer added a commit that closed this issue
@gibson042 gibson042 Core: Extend QUnit.config.urlConfig to support select-one dropdowns
To make it easier for projects like jQuery UI to provide a dropdown that
let's the user select the jQuery Core version to test against. Can
display any key/value pairs (or just keys). Selection will be available
via `location.search` and parsed as `QUnit.config`.

Fixes gh-385
Closes gh-443
1af7edb
@jzaefferer jzaefferer added a commit to jquery/api.qunitjs.com that referenced this issue
@gibson042 gibson042 Config: Document urlConfig options b191fbc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.