One great side effect of utilizing the agile approach to software design is the first thinking about, at lease as well as one can given the available information, the desired end result. This is typically started a failing test in the Test Drive Development (TDD) camp. However, the more I am exposed on RSpec the more I like the idea of design that is driven by specifications that are fulfilled in short, iterative cycles. Therefore, instead of having a "failing test" one would have an "empty executable specification." (If you could not already tell, I am not attempting to coin a new phrase. The
expression "empty executable specification" is neither clever nor catchy. To be honest, I really do not know what else to call it.) In fact, it is the use of existing terms in TDD that do not really communicate the great results of TDD.
The rSpec overview page discusses the confusion that results from the use of much of the TDD design processes described as "tests" and the clarification that Behavior Driven Development (BDD) semantics provides:
However, with the ubiquity of testing related terminology in TDD and its supporting frameworks, it is no surprise that it takes beginners some time to get to the understanding that TDD isn't about testing at all… if they ever do. The aim of BDD is to address this shortcoming and, by using terminology focused on the behavioural aspects of the system rather than testing, attempt to help direct developers towards a focus on the real value to be found in TDD at its most successful, or BDD as we call it.
The words you use do matter. I have found that management and quality assurance (QA) personnel more quickly identify with what the behavioral outcomes of an application may be rather than a design methodology called "'Test Driven' Development." After all, management says, "Why would you write a failing test before any implementation code? Just code and then test it. Isn't QA to do the extensive testing?"
The RSpec overview page goes on to say:
RSpec is a framework for practicing Behaviour Driven Development (BDD) in Ruby….RSpec provides a framework for writing what we call executable specifications of program behaviour.
So, just like the solid, TDD practice of not writing any code until you first have a failing test, with RSpec and Ruby you first write "empty executable specifications."
For example, RSpec when run produces what appears to be a specification list. Let's look at an example I create the following Ruby file called example.rb with the following code:
context "TDD methodologies" do
specify "should use more behaviorally based terminology" do
end
end
When run with the -f s option to the spec command, here is the outcome:
Note that it looks like a specification. It states that, "TDD methodologies should use more behaviorally based terminology." Also note that there is no code asserting that the implementation is using behaviorally based terms. Therefore, in my poor attempt to define it, it is an empty executable spec.
An example of an executable spec that is not empty would be:
context "TDD methodologies" do
specify "should use more behaviorally based terminology" do
@tdd_framework.should_be_called_BDD
end
end
In summary, there is no doubt a better term than "empty executable specification" to use to label the initial spec. Regardless of what one calls it, RSpec can provide an outline for writing executable specifications of program behavior and therefore guiding the design of the application.
