Practical considerations
The examples in this appendix have been necessarily simple. In practice, we can write tests that ensure the correct operation of quite complicated behaviors.
Ideally, we keep our tests as brief and simple as possible, even when the behaviors they are testing are intricate. By writing tests for a few specific scenarios, we can build reasonable certainty that we are fully testing the behavior even though we do not have a test for every possible set of inputs.
However, it is possible that an error is observed in our code even though we have written tests for it. When tests pass and yet an error occurs, the correct response is not to immediately fix the problem, but rather to first write a new test for the behavior that fails. This way, we can not only verify that the problem is solved when we correct the code, but also introduce an additional test that will help us avoid regressions in the future.
QUnit can be used for functional testing in addition to unit testing. While unit tests are designed to confirm the correct operation of code units (methods and functions), functional tests are written to ensure appropriate interface responses to user input. For example, in Chapter 12, Advanced DOM Manipulation, we implemented a table-sorting behavior. We could write a unit test for a sorting method, verifying that once the method is called the table is sorted. Alternatively, a functional test could simulate a user's click on a table heading and then observe the result to check that the table is indeed sorted.
Note
Functional testing frameworks that work alongside QUnit, such as dominator.js (http://mwbrooks.github.io/dominator.js/) and FuncUnit (http://funcunit.com/), can help make writing functional tests and simulating events much easier. To further automate tests in a variety of browsers, the Selenium (http://seleniumhq.org/) suite can be used in conjunction with these frameworks.
To ensure consistent results for our tests, we need to work with sample data that is reliable and unchanging. When testing jQuery code that is applied to a dynamic site, it can be beneficial to capture and store a static version of the page to run tests against. This approach also isolates your code's components, making it easier to determine whether errors are caused by server-side or browser-side code.
Further reading
These considerations are certainly not an exhaustive list. Test-driven development is a deep topic, and a short appendix is not enough to cover it fully. Some online resources containing more information on the topic include:
Introduction to unit testing (http://qunitjs.com/intro/)
QUnit Cookbook (http://qunitjs.com/cookbook/)
The jQuery Test-Driven Development article by Elijah Manor (http://msdn.microsoft.com/en-us/scriptjunkie/ff452703.aspx)
The Unit Testing Best Practices article by Bob McCune (http://www.bobmccune.com/2006/12/09/unit-testing-best-practices/)
Many books on the topic also exist, such as Test Driven Development: By Example, Kent Beck, The Addison Wesley Signature Series and Test-Driven JavaScript Development, Christian Johansen, Addison Wesley.
