Enter the ninja

■ Cross-browser web application development is hard, harder than most people
would think.
■ In order to pull it off, we need not only a mastery of the JavaScript language,
but a thorough knowledge of the browsers, along with their quirks and inconsistencies,
and a good grounding in standard current best practices.
■ While JavaScript development can certainly be challenging, there are those
brave souls who have already gone down this tortuous route: the developers of
JavaScript libraries. We’ll be distilling the knowledge demonstrated in the construction
of these code bases, effectively fueling our development skills and
raising them to world-class level.

2.1 Debugging code

Similar tools have been developed for all major browsers:
■ Firebug—The popular developer extension for Firefox that got the ball rolling.
See http://getfirebug.org/.
■ IE Developer Tools—Included in Internet Explorer 8 and later.
■ Opera Dragonfly—Included in Opera 9.5 and newer. Also works with mobile
versions of Opera.
■ WebKit Developer Tools—Introduced in Safari 3, dramatically improved as of
Safari 4, and now available in Chrome.

There are two important approaches to debugging JavaScript: logging and breakpoints.

Good tests exhibit three important characteristics:

■ Repeatability—Our test results should be highly reproducible. Tests run repeatedly
should always produce the exact same results. If test results are nondeterministic,
how would we know which results are valid and which are invalid?
Additionally, reproducibility ensures that our tests aren’t dependent upon external
factors issues like network or CPU loads.

■ Simplicity—Our tests should focus on testing one thing. We should strive to
remove as much HTML markup, CSS, or JavaScript as we can without disrupting
the intent of the test case. The more we remove, the greater the
likelihood that the test case will only be influenced by the specific code that
we’re testing.

■ Independence—Our tests should execute in isolation. We must avoid making
the results from one test dependent upon another. Breaking tests down into the
smallest possible units will help us determine the exact source of a bug when
an error occurs.

2.3.1 QUnit
QUnit is the unit-testing framework that was originally built to test jQuery. It has since
expanded beyond its initial goals and is now a standalone unit-testing framework.
QUnit is primarily designed to be a simple solution to unit testing, providing a minimal,
but easy to use, API.

QUnit’s distinguishing features are as follows:
■ Simple API
■ Supports asynchronous testing
■ Not limited to jQuery or jQuery-using code
■ Especially well-suited for regression testing

More information can be found at http://qunitjs.com.

2.3.3 JsUnit
JsUnit is a port of the popular Java JUnit testing framework to JavaScript. While it’s still
one of the most popular JavaScript unit-testing frameworks around, JsUnit is also one
of the oldest (both in terms of the code base age and quality). The framework hasn’t
been updated much recently, so for something that’s known to work with all modern
browsers, JsUnit may not be the best choice.
More information can be found at www.jsunit.net/.


Building upon that, we introduced the concept of the assertion, and we created
a simple implementation that will be used throughout the remainder of this
book to verify that the code does what we intend it to do.

■ Finally, we looked at how to construct a simple test suite capable of handling
asynchronous test cases. Altogether, these techniques will serve as an important
cornerstone to the rest of our development with JavaScript

from the secrets of the javascript ninja