Manual:JavaScript unit testing/QUnit guidelines

QUnit comparisons
If at all possible use comparing functions such as,   etc. instead of. In most unit testing because it is more useful to have both the expected value and resulting value available to the debugger. When using  it forces one to do the contrary and make comparison inline (since   only takes one value). In case of a failure,  only reports "Passed" or "Failed", whereas   (having both values), can output useful debug information. This is especially important when working with test reports generated externally (eg. from Jenkins) in which case the test report is all you have.

In cases where the exact value is too variable or doesn't matter, e.g. checking whether  is defined, then one can at least do a type check. Or a length check in case of strings. Suppose a variable is declared early and populated later, then you'll want to know more and a type check would report the type of value it contains when it's not what you expected. Below example is using since JavaScript's built-in   is flawed.

In the above example the report includes not only the failure ("type is not array"), but also what it actual value was ("result type: string"). This is possible because QUnit is given the type-value instead of the result of comparing the type.

When dealing with objects (such as arrays, object literals and other objects) one can't use  to compare the key/value pairs. In such case one has to use  which will loop over the object and compare the key/values themselves:

Test elements
The  element can be used to add extra elements to manipulate, and will be automatically reset after each test (see ). The element is styled with  with these, it won't be obstructing the result, without affecting code that relies on the affected elements to be visible (instead of  ).