Implement multi-value support for urlConfig UI #385

Closed
dmethvin opened this Issue Dec 27, 2012 · 7 comments

Comments

5 participants
@dmethvin

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

This comment has been minimized.

Show comment
Hide comment
@Krinkle

Krinkle Dec 28, 2012

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: '...'
});
Member

Krinkle commented Dec 28, 2012

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

This comment has been minimized.

Show comment
Hide comment
@JamesMGreene

JamesMGreene Dec 28, 2012

Member

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

Member

JamesMGreene commented Dec 28, 2012

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

gibson042 added a commit to gibson042/qunit that referenced this issue Apr 19, 2013

gibson042 added a commit to gibson042/qunit that referenced this issue Jan 3, 2014

@gibson042 gibson042 referenced this issue in qunitjs/api Jan 24, 2014

Closed

Config: Document urlConfig options #42

@leobalter

This comment has been minimized.

Show comment
Hide comment
@leobalter

leobalter Jan 24, 2014

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.

Member

leobalter commented Jan 24, 2014

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

This comment has been minimized.

Show comment
Hide comment
@scottgonzalez

scottgonzalez Jan 24, 2014

Contributor

@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.

Contributor

scottgonzalez commented Jan 24, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@leobalter

leobalter Jan 24, 2014

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.

Member

leobalter commented Jan 24, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin Jan 24, 2014

@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.

@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

This comment has been minimized.

Show comment
Hide comment
@Krinkle

Krinkle Jan 27, 2014

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 :)

Member

Krinkle commented Jan 27, 2014

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 added a commit to qunitjs/api that referenced this issue Jan 29, 2014

jzaefferer added a commit to qunitjs/api that referenced this issue Jan 31, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment