HTML and CSS Reference
In-Depth Information
3.1.1 Behavior-Driven Development
Behavior-driven development, or BDD, is closely related to TDD. As discussed in
Chapter 2,
The Test-Driven Development Process,
TDD is
not
about testing, but
rather about design and process. However, due to the terminology used to describe
the process, a lot of developers never evolve beyond the point where they simply
write unit tests to verify their code, and thus never experience many of the advantages
associated with using tests as a design tool. BDD seeks to ease this realization
by focusing on an improved vocabulary. In fact, vocabulary is perhaps the most
important aspect of BDD, because it also tries to normalize the vocabulary used by
programmers, business developers, testers, and others involved in the development
of a system when discussing problems, requirements, and solutions.
Another “double D” is Acceptance Test-Driven Development. In acceptance
TDD, development starts by writing automated tests for high level features, based
on acceptance tests defined in conjunction with the client. The goal is to pass
the acceptance tests. To get there, we can identify smaller parts and proceed with
“regular” TDD. In BDD this process is usually centered around
user stories
, which
describe interaction with the system using a vocabulary familiar to everyone involved
in the project. BDD frameworks such as Cucumber allow for user stories to be used
as executable tests, meaning that acceptance tests can be written together with
the client, increasing the chance of delivering the product the client had originally
envisioned.
3.1.2 Continuous Integration
Continuous integration is the practice of integrating code from all developers on
a regular basis, usually every time a developer pushes code to a remote version
control repository. The continuous integration server typically builds all the sources
and then runs tests for them. This process ensures that even when developers work
on isolated units of features, the integrated whole is considered every time code
is committed to the upstream repository. JavaScript does not need compiling, but
running the entire test suite for the application on a regular basis can help catch
errors early.
Continuous integration for JavaScript can solve tasks that are impractical for
developers to perform regularly. Running the entire test suite in a wide array of
browser and platform combinations is one such task. Developers working with
TDD can focus their attention on a small representative selection of browsers,
while the continuous integration server can test much wider, alerting the team of
errors by email or RSS.
