Our stop()/start() API isn't the greatest. Yehuda had some ideas for making that more convenient, outlined here: https://gist.github.com/2138c7bf20da83e823e8

Worth noting as well: nodeunit passes in a test object to each test, where the test has to call test.done() in the end. Each test gets its own instance, so there's no risk of one async test bleeding into another, like it currently can happen in QUnit. We should look into providing something similar for QUnit.

As James suggested elsewhere, a Getting Started page can cover:

• getting files with bower or npm (#40)
• using directly or with AMD (#50)
• the most popular CI integrations (#42)

Basically need to move the stuff that tells people how to contribute. Use this as a reference, if needed: https://github.com/jquery/jquery/blob/master/CONTRIBUTING.md

Per jquery/2012-dev-summit#60.

See the header of https://github.com/jquery/qunitjs.com/blob/master/resources/intro/qunit.js

I was really surprised to discover how much fail went into the re-organized docs section of the new qunitjs site. Major, major step backwards in my opinion.

Here's what needs to be fixed, since these are all regressions from the old docs that seriously detract from readability:

• method names should also show method arity the expected arguments - presently, instead of being shown a quick-to-read and helpful list of all methods and their expected arguments, the user is presented just the raw names of the API methods, with a short description of them. Any clue as to what arguments a method takes is trapped behind a click and a page load.
• category groupings should be shown at the documentation root. At first I didn't even notice that the categories are listed in the right column, but then the category names where unfamiliar and confusing. I understand the purpose of giving each category its own page and url, but unless live-search is implemented (like on api.jquery.com), index of the documentation section is a barrier to entry for users both new and old.
• ordering should be logical, not alphabetical. On the jQuery.com QUnit docs, all APIs are grouped by their functional grouping, and are presented in a, err, logical order rather than an alphabetical one.
• whitespace, just look at all that whitespace. I'll gripe about the fontsize later, but just take a good, hard look at how much whitespace is on that alphabetized docs page. The previous docs page let you view at least 14 or 15 methods at at time on a decent sized monitor. The current docs page limits you to a scant 5!

These are just nice-to-haves:

• why is the font for API methods 22px?
• category names provide less insight into what their APIs do -- granted this is a bit subjective, but feel like the "Testing," "Assertion," and "Async Testing" categories provide much more insight that the current arrangement, but again that's debatable
• less green, this whole things looks like its Kermit the Frog's last colonoscopy video
• can the whole design just be simplified? Take a quick look at 2 other popular test frameworks documentation sites, Mocha and Jasmine. Now, I know that design is entirely subjective, but what strikes me is that Qunitjs.com has problems with clutter, organization and lack of clarity. To get any useful information, you're a minimum of 2 clicks before getting at it. Given that its a testing framework with a relatively small surface area, is that really necessary? Couldn't the same set of problems be solved by a simple, uncluttered landing page that lists all API methods and a few examples of simple qunit tests to give them an overview on why QUnit is awesome (and why oh why do you lead off with HTML test setup? Is that the most relavant information for someone new to QUnit? absolutely not. show them tests. show them how easy qunit is. don't show them an HTML document as the first point of entry. /rant ).

Here's a quick demonstration of all these regressions working together in terror, vs the old, beloved docs site:

At least this was succinct...

Footer stuff is easy to miss. Maybe add a Download page?

We should get at least one book in QUnit listed in the footer. Here's one from Packt: http://www.amazon.com/Instant-Testing-QUnit-Dmitry-Sheiko/dp/1783282177/

Given QUnit.jsDump.parse's utility in defining custom assertions (and the unit tests backing its behavior [1] [2] [3]), the method appears to be part of the public API. Can someone on the team confirm this?

If so, then the documentation should be extended to describe its usage.

[1] https://github.com/jquery/qunit/blob/81d499b0fb06970b5f52185b8153416341c0d49e/test/test.js#L394-L402
[2] https://github.com/jquery/qunit/blob/81d499b0fb06970b5f52185b8153416341c0d49e/test/test.js#L667-L685
[3] https://github.com/jquery/qunit/blob/81d499b0fb06970b5f52185b8153416341c0d49e/test/test.js#L702-L728

Please provide a working sample in a zip file including all necessary files.
Please refer
qunitjs/qunit#444

Opening issue as recommended.

Few changes suggested for home page are /resources/.. to be changed to ./resources/..

Regards

QUnit has a few really nice/plugins but I think we should promote it more and encourage more people to build/use them.

On the homepage there's totally no emphasize on the fact that qunit plugins/themes exist, while I do consider it an important feature of qunit. Any thoughts are welcome?

As of 91afca0, The latest version of qunit is 1.18.1. Both at http://code.jquery.com/qunit/ and https://qunitjs.com/, the latest version is still stated as 1.18.0.

This was originally titled "Reference to strictEqual should be deepEqual?"

Reading the cookbook quickly, you see the example for Equal, with a passing reference to strictEqual. Which is then following by an example for deepEqual.

If you're reading this quickly for the first time (like I was), it looks as though this is a typo and the mention of strictEqual is in fact meaning deepEqual, since it starts off reiterating the fact that it uses "===".

An example of all 3 might illustrate the differences between them better.

Hi, in QUnit cookbook there is an error in documentation at "http://qunitjs.com/cookbook/#asserting-results" equal section. At the end of the paragraph it appears "When you need a strict comparison (==), use strictEqual() instead." and it should be "When you need a strict comparison (===), use strictEqual() instead." Three equals strict comparison.

Moved from qunitjs/qunit#398

• From: @betitoglez
• Timestamp: 2013-01-25T02:10:05-08:00

Grunt 0.3.17 now requires any project that is linting the gruntfile to include a "use strict" pragma as the first line, we should add one to any project that's linting the gruntfile (or all of them, really). @ronchalant offered to take care of this :)

see jquery/2012-dev-summit#4

Use parts of the logo for that.

Different repo, but pinging @zrmccarthy again to see if he could create this as well.

Basically need to move the stuff that tells people how to contribute. Use this as a reference, if needed: https://github.com/jquery/jquery/blob/master/CONTRIBUTING.md

Per jquery/2012-dev-summit#60.

Mostly used for release annoucements. Tweets could then point to blog posts with release notes, instead of just the GitHub tag.

At least link to a Sinon.js+QUnit example, if there is one.

Could go into the Cookbook, under "Refactoring tests". Something like this:

• Problem: You have several tests that duplicate a lot of code to assert something [add example here]
• Solution: Write a custom assertion to reduce duplication [example of writing and using custom assertion]
• Discussion: Discussion of QUnit.push, QUnit.assert, QUnit.extend, why extending QUnit.assert doesn't result in new globals, how to add those manually.

Add API entries for QUnit.push, QUnit.assert, QUnit.extend, these aren't documented currently.

This is a good starting point: http://stackoverflow.com/questions/19471956/how-do-i-extend-qunit-with-new-assertion-functions

The pygments plugin works with docpad-render, so it should be possible to use partials in that context as well.

Seeing as both of the copyright owners are team members and all...

The QUnit demo on the home page is still using QUnit v1.14.0:
http://qunitjs.com/resources/example-index.html

Maybe on other pages as well. Make them more discoverable in general.

"A non-strict comparison assertion, checking for inequality"

Shouldn't this say:
"A strict comparison assertion, checking for inequality"

Right now they look weirdly "boxed". I'm no css expert, so I'd rather let someone else handle this ;)

Covering how to integrate QUnit with various CI environments:

• Jenkins, Travis, CircleCI
• BrowserStack, Sauce Labs, testling
• TestSwarm
• PhantomJS
• testem, testacular
• Karma
• Grunt
• Gulp

But also other environments:

• getting files with bower or npm (#40)
• using directly or with AMD (#50)

We distribute QUnit via npm as "qunitjs". It should be easy to reference the QUnit files from a html file with ../node_modules/qunitjs/qunit/qunit.js.

Once we also distribute it via bower, we should document that as well.

The last time I worked on these docs, we had a reasonable syntax highlighter in place that made the code examples look quite nice. Somehow, in the meantime, they've regressed into something virtually unbearable to look at it, let alone read and grok:

Cookbook still uses global expect() calls.

We list several projects that are likely not working anymore, are useless by now or have some other issue. For example, both pavlov and specit haven't been updated in several years. qunit-helpful is very limited value since we improve output for the ok assertion. qunit-once goes against the recommendation to keep tests atomic.

Make the site consistent with what's in the repository. First step of many to make add-ons more prominent. Most people using QUnit have no idea they exist.

List the phantomjs addon, provide demos for themes etc

The demo should use the CDN instead.

We may want to keep redirects to http://code.jquery.com/qunit/qunit-1.13.0.js and http://code.jquery.com/qunit/qunit-1.13.0.css from /resources/qunit.js and /resources/qunit.css. Though they shouldn't be used anywhere.

• referer_domain - access logs for /resources/qunit.js - Splunk Search

At this point we're using DocPad only for the code highlighting, which we should be able to implement in a grunt task. Maintaining the layouts seperate from web-base-template isn't really worth the effort, just to lower the barrier to entry a little bit.

Content can still be edited without having to install anything at all. Bigger changes need to be tested against the target platform anyway, and that is WordPress, not DocPad.

ALA is a great reference: http://www.alistapart.com/copyright/

In short: Code samples should be free for use without attribution. Content should be free for use with attribution. Site design should not be available for use.

We should have a migration guide to the QUnit 2.0 APIs ready for the 1.16 release. This could use the format of jQuery UI's upgrade guides (like the one for 1.11).

I'm also planning a blog post to go on blog.jquery.com along with the 1.16 release, which could quote from the upgrade guide and point out ongoing discussions like the nested suites. I could also include the team photo...

QUnit has a Twitter account: https://twitter.com/qunitjs

The footer template has a Twitter link in place, though the surrounding links look like those should be the same across all sites. Could instead add that next to the Bugs link?

On http://qunitjs.com/plugins/, @jdalton’s qunit-cli has been updated to qunit-extras.

Please add a link on the Addons page to my new QUnit HTML assertion addon! ❤️

It originated from qunitjs/qunit#368, where @jzaefferer reminded me to create this issue.

Repo: https://github.com/JamesMGreene/qunit-assert-html
Description: A QUnit addon for assertion methods to compare two HTML strings for equality after a normalization process.

The "Quick access" looks like a clickable input field that would select the text on-click, but nothing happens (I do recall it happening in earlier staged versions on some of the other sites).

It also misses one for the css.

The intro article links to jquery-cookbook.com which is broken because it uses SVN.

Shadow is too big (cut off). It's not in the embedding (e.g. css window too small), the image itself has it cut off.

While at it, the shadow could do with less. It is a bit excessive in my opinion.

the left side alignment is messy
the right side has no indentations at all
there are some problems with vertical alignment as well

Test function (tests.js):

test("errors should be hidden on click", function() {
    $('input').click();
    equal($('.has-error').is(':visible'), false);
})

HTML page (tests.html):

<html>
<head>
  <meta charset="utf-8">
  <title>Javascript tests</title>
  <link rel="stylesheet" href="qunit.css">
</head>
<body>
  <div id="qunit"></div>
  <div id="qunit-fixture">
    <form>
      <input name="text">
      <div class="has-error">Error text</div>
    </form>  
  </div>
  <script src="https://code.jquery.com/jquery-2.1.4.min.js"></script>
  <script src="qunit.js"></script>
  <script src="tests.js"></script>
</body>
</html>

I'm using QUnit v1.18.0, Chrome 44.0.2403.130 (64-bit) and jQuery 2.1.4. When I open tests.html, the browser enters into an infinite loop. Is this is a bug on QUnit or on my code? Thanks.

The code examples in the intro article are excessively wide, resulting in horizontal scrolling.

Along with the migration guide (#86) we should publish a blog post that outlines the new 2.0 APIs and our plans for nested suites (link to the PR).

This can also talk a bit about the team behind the project, including the team photo from Chicago.

The code sample to the equal assertion section has duplicated assertions as example. Lines 2 and 5 of that code are exemplifying the same thing:

line 2 equal( 0, 0, "Zero; equal succeeds" );
line 5 equal( 0, 0, "Zero, Zero; equal succeeds" );

This content repo should have a license file like in https://github.com/jquery/api.qunitjs.com/blob/master/LICENSE-MIT.txt