Introducing BDD with RSpec
Behavior Driven Development (BDD) is an approach for software development combining the advantages of Test Driven Development and Domain Driven Design. It helps the team of the project focus on the exact requirements of the client in a verifiable manner.
In TDD, we had acceptance tests that verify the correctness and completeness of the feature once they pass. Those tests are written by the developers at the beginning of an iteration. A weak point though is that those tests were written in a programming language (java, ruby, ..) nothing that the customer can understand. BDD introduces a common vocabulary among all people, that is simple text, something that even the customer can understand and write.
RSpec is a ruby framework that helps with the implementation of BDD. It is really an interesting project.
RSpec started with what they call now the "spec framework", this framework describes pieces of the application model through by specifying characteristics and actions that can be verified through the code. check the example at the rspec site
The second part of rspec is called the "story framework".. the story framework is the same old rbehave project that was started by Dan North back in June 2007. Five months later, rbehave joined rspec and became the story framework of rspec.
The story framework enables the team to document user stories in simple text format written in a specific structure. A story is described and a set of scenarios are written to describe how the system should behave. The scenario is composed of several steps that can be programmatically implemented, so we end up in having an executable user story.
The example at the rspec homepage shows how this framework works.
the scenarios are written using a small set of keywords "Given, And, When, Then" that describe the steps of the scenario. "Given" declares the steps that describe the context, it can be used to setup that context for our test. "When" describes the action that is made. "Then" describes the expected results or expected final state the system after the action, "Then" steps implementation usually have the "actual.should ==expected" lines that are very similar to the ordinary assert instructions in most testing framworks.
One important point to consider is that the Scenarios should be written in a very specific manner. The developers won't be able to implement steps of abstract nature. for example:
when you are writing scenarios that describe that validation of a user model
DO NOT write:
Given the user has some invalid values
When the user submits
Then the user should be invalid
Instead, write:
Given the user entered his email as invalidemail
And the user left his name blank
When the user submits
Then the user should be invalid
David Chelimsky, one of rspec core team shows how to write plain text stories having the implementation of steps in a separate file which makes the stories look more elegant.
In TDD, we had acceptance tests that verify the correctness and completeness of the feature once they pass. Those tests are written by the developers at the beginning of an iteration. A weak point though is that those tests were written in a programming language (java, ruby, ..) nothing that the customer can understand. BDD introduces a common vocabulary among all people, that is simple text, something that even the customer can understand and write.
RSpec is a ruby framework that helps with the implementation of BDD. It is really an interesting project.
RSpec started with what they call now the "spec framework", this framework describes pieces of the application model through by specifying characteristics and actions that can be verified through the code. check the example at the rspec site
The second part of rspec is called the "story framework".. the story framework is the same old rbehave project that was started by Dan North back in June 2007. Five months later, rbehave joined rspec and became the story framework of rspec.
The story framework enables the team to document user stories in simple text format written in a specific structure. A story is described and a set of scenarios are written to describe how the system should behave. The scenario is composed of several steps that can be programmatically implemented, so we end up in having an executable user story.
The example at the rspec homepage shows how this framework works.
the scenarios are written using a small set of keywords "Given, And, When, Then" that describe the steps of the scenario. "Given" declares the steps that describe the context, it can be used to setup that context for our test. "When" describes the action that is made. "Then" describes the expected results or expected final state the system after the action, "Then" steps implementation usually have the "actual.should ==expected" lines that are very similar to the ordinary assert instructions in most testing framworks.
One important point to consider is that the Scenarios should be written in a very specific manner. The developers won't be able to implement steps of abstract nature. for example:
when you are writing scenarios that describe that validation of a user model
DO NOT write:
Given the user has some invalid values
When the user submits
Then the user should be invalid
Instead, write:
Given the user entered his email as invalidemail
And the user left his name blank
When the user submits
Then the user should be invalid
David Chelimsky, one of rspec core team shows how to write plain text stories having the implementation of steps in a separate file which makes the stories look more elegant.
Comments