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 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 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. Alternately, 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. Dedicated functional testing frameworks such as Selenium (http://seleniumhq.org/) can be used for more advanced scenarios.

In order to ensure consistent results for our tests, we need to work with sample data that is reliable and unchanging. When testing the 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 the server-side or the browser-side code.