Here at Brightbox we are making heavy use of RSpec and Cucumber as we develop our next generation internal systems. These let us write specifications, in English and in code, for how the systems should behave. The specifications document the system for future reference and provide an automated test suite to prove that things are working as they should.
We chose RSpec because of its philosophy of “getting the words right”; code is often easier to write than it is read. As these specifications are also our internal documentation they must be easy to read as well.
However, as some of this Behaviour-Driven and Story-Driven development is pretty new, there isn’t much guidance on best practice, especially when it comes to the “User Stories” (which form the basis of the system’s acceptance tests). With that in mind, we thought we’d share our basic process we follow for each new feature.
(Download the original presentation here)
By the way, there’s a very subtle bug in the code; no prizes if you spot it!
