CODEWITHSUNDEEP
javascriptunit-testingqunit
John Freeman
John Freeman

Reputation: 2692

How to get QUnit to print backtrace on exception?

When an exception occurs in my QUnit tests, all it will say is

Died on test #n: message

How do I get it to print a backtrace or some other location information so that I can see where the exception occurred?

Upvotes: 5

Views: 1503

Answers (2)

marue
marue

Reputation: 5726

edit: While answering this, the suspicion arised in me that is not what you wanted to ask. So i edited the answer to show this, probably more usefull part, first:

Because you write "When an exception occurs in my QUnit tests" let me explain the concept of testing in a bit more depth:

First of all: The exception does not occur in your QUnit tests, but in your code. The good news is: qUnit is in your case doing exactly what it should do: it tests your code, and as your code is faulty, your code raises an exception when being tested.

As qUnit is a testing environment, it is not responsible for delivering exception tracebacks. It is only there to check if the functionality you implemented works the way you expect it to work, not to track down bugs. For such purpose tools like FireBug or Safari's developer tools are much more suitable.

Let me describe a scenario:

  1. you write a function
  2. you eliminate bugs from it with (ie.) FireBug
  3. you write a qUnit testcase to proove the function really does what you want it to do - tests pass
  4. (and now it gets interesting, because this is what testing really is for) You add some additional funcionality to your function, because it is needed
  5. If you have done everything right, your tests pass, and you can be sure everything will continue to work as expected because they do (if you have written them well)

To sum that up: Tests are not for debugging, but for assuring things work the way you think they work. If a bug appears, you do not write a test to solve it, but you write a test to reproduce it. Then you find the bug, remove it, and the test will pass. If the bug is being reinvented later on (ie. because of code changes) the test will fail again, and you immediately know the bug is back.

This can be taken even further by establishing test driven development, where you write tests before you write the functionality itself. Then the scenario above would change to this:

  1. you write a test, describing the expected results of your code
  2. you write the code, when bugs appear you track them down with (ie.) Firebug
  3. while progressing, one test after the other will start to pass
  4. when adding additional functionality, you first write additional tests

There are two major advantages in doing so:

  1. you can be sure you have the necessary tests and
  2. you are forced to pin down exactly what you want your code to do, because otherwise you can't write the tests.

Happy testing.

edit end - original answer follows, just in case it is needed.

When using QUnit i would strongly recommend to follow the approach shown on the jQuery documentation site http://docs.jquery.com/Qunit:

To use QUnit, you have to include its qunit.js and qunit.css files and provide a basic HTML structure for displaying the test results:

All you have to do is to load qunit.js and qunit.css files, then put this snippet to your page to get visual feedback about the testing process:

<h1 id="qunit-header">QUnit example</h1>
<h2 id="qunit-banner"></h2>
<div id="qunit-testrunner-toolbar"></div>
<h2 id="qunit-userAgent"></h2>
<ol id="qunit-tests"></ol>
<div id="qunit-fixture">test markup, will be hidden</div>

Doing so results in a neatly rendered and interactive console showing exact reports about the test results. There is a row for each test showing if it passed or not, clicking on that row unfolds the results of each single test. This will look somewhat like this:

qUnit test results

To customize the error messages qUnit shows, you just have to append the string to be shown to your test. So instead of

ok($('.testitem:first').is(':data(droppable)'))

use

ok($('.testitem:first').is(':data(droppable)'),
    "testitem is droppable after calling setup_items('.testitem')");

to get the error message shown in the picture. Otherwise qUnit falls back to some standard error message associated with the used test.

Upvotes: 0

Charles Anderson
Charles Anderson

Reputation: 20039

I don't think it is possible to make QUnit give you a trace of where the error happened. Your code has generated an exception, which QUnit has caught and reported. If you tick the 'notrycatch' checkbox at the top of the QUnit results, your tests will run again, but this time QUnit won't catch the exception. Your browser may then give you more information on what actually happened, but it will depend on what the error was.

Upvotes: 5

Related Questions