HTML and CSS Reference
In-Depth Information
with another human to move some cash from account A to account B, we simply
log in from the comfort of our couch and get the job done in a couple of minutes.
Saves us time and saves the bank time.
Automated testing
provides a solution to the manual testing process. Instead
of filling out that form
one more time
and hitting submit to see if the client-side
validations trigger as expected, we can instruct software to perform this test for
us. The advantages are obvious: given a convenient way to run the automated test
we can test in numerous browsers with a single effort, we can rerun the test at any
later stage, and the test may even run on some schedule that requires no manual
interaction whatsoever.
Automated software testing has been around for quite a while, even for
JavaScript. JsUnit dates back to 2001, Selenium came along in 2004, and since then
an incredible amount of tools have emerged. Still, automated testing seems to have
less momentum in the JavaScript/web development community than most other
programming communities. In this chapter we'll investigate one means to automate
software testing, the unit test, and how it applies to the world of JavaScript.
A unit test is a piece of code that tests a piece of production code. It does so
by setting up one or a few more objects in a known state, exercising them (e.g.,
calling a method), and then inspecting the result, comparing it to the expected
outcome.
Unit tests are stored on disk and should be easy and fast to run; if tests are
hard or slow to run, developers are less likely to run them. Unit tests should test
software components in isolation. They should also run isolated—no test should
ever depend on another test, tests should be able to run simultaneously and in any
order. In order to test components in isolation, it is sometimes necessary to
mock
or
stub
their dependencies. We will discuss mocking and stubbing in context in
Part III,
Real-World Test-Driven Development in JavaScript
and in more detail in
Chapter 16,
Mocking and Stubbing
.
Having unit tests stored on disk, and usually stored in version control along
with the production code, means we can run tests at any time:
•
When the implementation is complete, to verify its correct behavior
•
When the implementation changes, to verify its behavior is intact
•
When new units are added to the system, to verify it still fulfills its intended
purpose
