Bugfixes + Features for QUnit testrunner

[chadmyers]

We're using QUnit at my work for testing and we found a sporadic bug with the test timing which I believe is due to the use of calculations with Date() instead of Date().getTime().

We also added the following features:

1.) Display the number of GOOD/PASSED tests in the stats display (instead of just the failed ones)

2.) beforeEach() and afterEach() for more XUnit-style setup/teardown behavior.

3.) Appending a hidden results div with a special ID to make it easier to integrate QUnit tests into your CI build with things like WatiR or WatiN.

Please consider the patch below to see if there's anything you might find useful for contributing into the trunk (either code or ideas).

[chadmyers]

Testrunner patch for trunk rev 5800.

[chadmyers]

Full test runner source (for your convenience)

[joern]

Commited [5815], improving the date handling (not much difference) and adding an id and two spans with classes to the result element, also documented how to read that microformat: http://docs.jquery.com/QUnit#Integration_into_Browser_Automation_Tools

I'd need a usecase for the other two things: With the numbers for all and failed tests, the number of succesful tests can be computed, why add the code to count them, too? beforeEach/afterEach is less useful in the context of QUnit, where those would have a global scope - in contrast to eg. JUnit's setUp/tearDown, which are local to a single TestCase?.

Please reopen the ticket with usecases for those, and I consider adding them, too.

[chadmyers]

@joern This is great, thank you!

As for the use cases: 1.) Number of Successful Tests: Agreed we don't need the extra variable to track it, but the output display is nice. Several of our developers thanked me for adding that to our build. It's minor, granted, but it's nice to see more than just 0 failures all the time :)

2.) As for beforeEach/afterEach, I don't understand. These run before each individual test in the suite, not just the entire suite. So it is local to each test case, but it's common setup/teardown needed for each, individual test() call. This one I consider very important and required for any sort of XUnit-style testing.

Thanks again for considering these. Sorry to be a pest, but I think these changes make QUnit even better!