Add QUnit to the third party directory

QUnit is a powerful and easy-to-use JavaScript unit testing framework

Security
These libraries will only be used for internal testing only and will not be shipped.  It will not have any security impact on chrome.

Why QUnit?
1. Open source and good community support
2. Easy to configure which makes it easy to integrate with the browser test framework
3. Easy code coverage support with blanket.js
4. Its TDD style is consistent with our C++ GTest.
5. Support DOM interactions (unlike the JS2Gtest framework)

BUG=378537
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=276055

[cpu_(ooo_6.6-7.5), 2014-05-29 19:54:13]

why 3 frameworks?

[kelvinp, 2014-05-29 20:05:07]

The three frameworks serve different roles and they work together to
provide a complete solution.

*QUnit* is the unit testing framework that handles test running and
reporting.

*BlanketJS* is responsible for code coverage.

*SinonJS* is a GMock like framework that allows you to mock/stub existing
components to make unit testing easier.

Kelvin


On Thu, May 29, 2014 at 12:54 PM, <cpu@chromium.org> wrote:

> why 3 frameworks?
>
>
> https://codereview.chromium.org/300363002/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Sergey Ulanov, 2014-05-30 05:33:26]

I suggest splitting this into 3 CLs, one for each library.

Please don't use versioned directories (e.g. third_party/qunit/src/qunit.js
instead of third_party/QUnit/1.14.0/qunit.js). Otherwise updating them would be
PITA.

It's better to use lower-case names for the directories in third_party, for
consistency with other third-party deps.

Also BUG= should be at the end of CL description. See
http://dev.chromium.org/developers/contributing-code#TOC-Change-List-Descript....

[jschuh, 2014-05-30 13:53:55]

This is all test only dependencies. So consider this your blanket rubber-stamp
for security, but I concur with Sergey's feedback on splitting and naming.

[kelvinp, 2014-05-30 17:33:59]

On 2014/05/30 05:33:26, Sergey Ulanov wrote:
> I suggest splitting this into 3 CLs, one for each library.
> 

Will Do.

> Please don't use versioned directories (e.g. third_party/qunit/src/qunit.js
> instead of third_party/QUnit/1.14.0/qunit.js). Otherwise updating them would
be
> PITA.

I think versioning is important though. Here is the scenario.

Say if someone need a newer version of QUnit, without versioning, he would
either need to
1. Update the QUnit to the version that he wants and make sure all existing code
is not broken.
2. Check-in the new version to a different source location and roll his own.

Most people won't have the time to do (1) so it is more likely for them to do
(2), which will need to
multiple copies of the libraries exist in different location of our code base.

Allowing different version of a same library allows some "breathing room" for
people to check-in a new version
of a library without forcing them to sign up to update all existing one in the
same time.
After the initial check-in, they can file bugs for the other OWNERS to upgrade
to the new version, etc.

What do you think?
 
> 
> It's better to use lower-case names for the directories in third_party, for
> consistency with other third-party deps.
> 

Will Do.

> Also BUG= should be at the end of CL description. See
>
http://dev.chromium.org/developers/contributing-code#TOC-Change-List-Descript....

Will Do.

[brettw, 2014-05-30 17:40:22]

I don't think we've ever supported more than one version of a third party
library at once, and I don't think it's something we should start doing. I would
definitely remove the versions from the paths.

[garykac, 2014-05-30 17:59:45]

On 2014/05/30 17:33:59, kelvinp wrote:
> On 2014/05/30 05:33:26, Sergey Ulanov wrote:
> > Please don't use versioned directories (e.g. third_party/qunit/src/qunit.js
> > instead of third_party/QUnit/1.14.0/qunit.js). Otherwise updating them would
> be
> > PITA.
> 
> I think versioning is important though. Here is the scenario.
> 
> Say if someone need a newer version of QUnit, without versioning, he would
> either need to
> 1. Update the QUnit to the version that he wants and make sure all existing
code
> is not broken.

This is the right answer here.  The bots will run the tests and any errors
should be fixed. We don't want to keep multiple versions of the library - it
just adds confusion.

The library updates shouldn't be difficult, but if they ever are, we have a
number of options:
* temporarily disable the broken tests until they are fixed
* temporarily keep the old version around and switch the broken tests to use it
until they are fixed.
But I doubt we'll ever need to do that.

Basically, it's unlikely that someone will ever need an older version, but it's
very likely that we'll update to a newer version of the library. We need to make
sure that updating the library doesn't require that we update the version number
every place where it is used.

[kelvinp, 2014-05-30 18:21:27]

On 2014/05/30 17:59:45, garykac wrote:
> On 2014/05/30 17:33:59, kelvinp wrote:
> > On 2014/05/30 05:33:26, Sergey Ulanov wrote:
> > > Please don't use versioned directories (e.g.
third_party/qunit/src/qunit.js
> > > instead of third_party/QUnit/1.14.0/qunit.js). Otherwise updating them
would
> > be
> > > PITA.
> > 
> > I think versioning is important though. Here is the scenario.
> > 
> > Say if someone need a newer version of QUnit, without versioning, he would
> > either need to
> > 1. Update the QUnit to the version that he wants and make sure all existing
> code
> > is not broken.
> 
> This is the right answer here.  The bots will run the tests and any errors
> should be fixed. We don't want to keep multiple versions of the library - it
> just adds confusion.
> 
> The library updates shouldn't be difficult, but if they ever are, we have a
> number of options:
> * temporarily disable the broken tests until they are fixed
> * temporarily keep the old version around and switch the broken tests to use
it
> until they are fixed.
> But I doubt we'll ever need to do that.
> 
> Basically, it's unlikely that someone will ever need an older version, but
it's
> very likely that we'll update to a newer version of the library. We need to
make
> sure that updating the library doesn't require that we update the version
number
> every place where it is used.

Will do.

[kelvinp, 2014-05-30 18:33:47]

PTAL

[cpu_(ooo_6.6-7.5), 2014-05-31 01:20:24]

some missing steps from
http://www.chromium.org/developers/adding-3rd-party-libraries

for example
open-source-third-party-reviews@google.com

Has not blessed the code.

[kelvinp, 2014-05-31 02:51:25]

Let we follow up with them
On May 30, 2014 6:20 PM, <cpu@chromium.org> wrote:

> some missing steps from
> http://www.chromium.org/developers/adding-3rd-party-libraries
>
> for example
> open-source-third-party-reviews@google.com
>
> Has not blessed the code.
>
>
> https://codereview.chromium.org/300363002/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[kelvinp, 2014-06-02 18:29:00]

Sent mail to open-source-third-party-reviews@google.com via a separate thread,
as we try not to expose google.com address in chromium reviews.

Updated licenses.py to exclude qunit as it is test code that is not shipped.

PTAL

[cpu_(ooo_6.6-7.5), 2014-06-04 22:16:23]

ok, ping my to my google address once license people have lg the changes.

[cpu_(ooo_6.6-7.5), 2014-06-07 02:27:58]

lgtm

[kelvinp, 2014-06-09 17:30:27]

The CQ bit was checked by kelvinp@chromium.org

[commit-bot: I haz the power, 2014-06-09 17:31:36]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/kelvinp@chromium.org/300363002/40001

[commit-bot: I haz the power, 2014-06-10 08:01:51]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  android_clang_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/android_clang_dbg/bui...)
  android_dbg_triggered_tests on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/android_dbg_triggered...)
  ios_dbg_simulator on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/ios_dbg_simulator/bui...)

[commit-bot: I haz the power, 2014-06-10 11:46:26]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-06-10 11:46:27]

Try jobs failed on following builders:
  android_dbg_triggered_tests on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/android_dbg_triggered...)

[kelvinp, 2014-06-10 16:37:43]

The CQ bit was checked by kelvinp@chromium.org

[commit-bot: I haz the power, 2014-06-10 16:39:39]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/kelvinp@chromium.org/300363002/40001

[commit-bot: I haz the power, 2014-06-10 16:44:22]

Change committed as 276055