CSC/ECE 517 Fall 2013/ch1 1w33 aa: Difference between revisions
No edit summary |
No edit summary |
||
Line 121: | Line 121: | ||
:4. [http://en.wikipedia.org/wiki/RSpec RSpec] | :4. [http://en.wikipedia.org/wiki/RSpec RSpec] | ||
== References == | |||
<references /> | |||
== External links == | |||
: | :1. [http://www.slideshare.net/MarkMenard/behavior-driven-development-with-rails Behavior driven development with Rails] | ||
: | :2. [http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/ Lifecycle] | ||
:3. [http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ Writing user stories] | |||
:4. [http://bob-roberts.net/2012/02/17/608/ Using Rspec and Capybara] | |||
:5. [http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber Difference between RSpec and Cucumber] |
Latest revision as of 00:55, 8 October 2013
Behavior Driven Development in Ruby on Rails
Behavior-driven development (also known as BDD) is an Agile development strategy that has been derived from Test Driven Development(also known as TDD). It was developed by Dan North in order to address the problems faced by TDD.
Introduction
Behavior Driven Development approach focuses on design, documentation and behavior rather than on tests. This approach enables more interactions between the client and the developer. The client specifies his functional specifications to the developer by writing user stories which describe how the system should perform when a certain condition is met. These user stories are then translated into tests using tools like RSpec and Cucumber. These tests are then run to check whether they satisfy the desired functional behavior. The business requirement is delivered when all the tests pass.
Figure-1. Steps for BDD<ref>http://msdn.microsoft.com/en-us/magazine/gg490346.aspx</ref>
Difference from other development strategies
Test-driven development (TDD)
Another type of Test Driven Development is Behavior-driven development (also known as TDD). In TDD, software developers write automated test cases before they write any code.
- • The first step of TDD is to write a failing test for a particular unit of functionality to be added.
- • The next step is to write a piece of code only to pass that failing test.
- • The last step would be to refactor the code so that it meets the requirement standards of the code.
Figure-2. Steps for TDD
Test Driven Development follows three rules.<ref>http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd</ref> They are:
- • One must not write any production code unless it is to make a failing unit test pass.
- • One must not write any more of a unit test than is sufficient to fail
- • One must not write any more production code than is sufficient to pass the one failing unit test.
Difference between TDD and BDD <ref>http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd</ref>
- • TDD’s main focus is on the tests while BDD mainly focuses on the behavioral specification from the user point of view.
- • With TDD, unit tests are written, whereas for BDD tests are written using “User Stories”.
- • TDD uses language which is intelligible to only the software programmers.
- • BDD uses language which is more easily understood by technical as well as non technical people.
For example, to define a class named Student, TDD will create StudentTest class containing required tests, whereas BDD will create StudentBehaviour class which will contain example methods to define the behaviour of Student class.
- • Due to BDD language being comprehensible by both technical as well as domain experts, the BDD involves the customers and the business partners in writing the scenarios for the tests.
- • Unlike tests which come after implementation, focusing on the behavior proves to be a better approach.
- • TDD methodology can lead to a number of failed tests before arriving at the correct result because it focuses mainly on implementation. But BDD does not require so many tests as its main focus is behavior thus resulting in less code.
Disadvantages of BDD
- • The user stories written by the customers might not be good quality and may have to be rewritten by the developer.
- • The customer might not have enough time to review the scenarios on a regular basis.
Examples of BDD with Ruby on Rails <ref>http://www.ryangreenhall.com/articles/bdd-by-example.html</ref>
In BDD, business requirements are identified by user stories. The user stories are described using the following format
As a [role] I can [feature] so that [reason]
Example to explain this-
As a Bank account holder I can login with my credentials so that I can check my account details
Once the user stories are written, the acceptance tests can be written for the user stories. The acceptance tests have the following format
Given [Context] When [Event Occurs] Then [Outcome]
Scenario: Enter a Login Page
Given I enter a valid username And I enter a valid password When I press the Login Button Then I should be redirected to the home page
These acceptance tests for the user stories are entered in the application as automated tests by the developer.
Implementation
Ruby on Rails uses various tools like Cucumber, Rspec etc to implement the user tests using Behaviour-driven development.
Cucumber <ref>http://cukes.info/</ref>
BDD makes the use of Cucumber for running automated acceptance tests. Cucumber specifies what a user should see and be able to do. Cucumber works with Ruby to help the software development teams describe how an application should behave. Cucumber is intelligible to both software developers as well as domain experts. It can serve both as documentation and automated tests.
Figure-3. Use of Cucumber<ref>http://infowarestudios.co.za/agile-testing-getting-agile-tests-incorporated-into-your-sprints-using-bdd-and-cucumber-in-c/</ref>
RSpec
RSpec mainly deals with unit tests which mean testing a class method in isolation from the rest of the application. So it guarantees that the model does what it is supposed to do, the controller does what it is supposed to do, etc. It explains the behavior of objects at the code level. It provides a simple and elegant syntax and works effectively with some other frameworks like Rails and Mocha library.
Figure-4. Use of RSpec<ref>http://i.stack.imgur.com/</ref>
RBehave <ref>http://dannorth.net/2007/06/17/introducing-rbehave/</ref>
RBehave is a framework based on the story framework from JBehave which describes behaviour at the application level. It is simpler than RSpec and eliminates the need to reuse code. The choice of frameworks depend on the level of granularity. RBehave and RSpec are often used as a combination to simplify BDD wordings.
See also
- 3. Cucumber
- 4. RSpec
References
<references />
External links
- 2. Lifecycle