CSC/ECE 517 Fall 2012/ch2a 2w26 aj: Difference between revisions
No edit summary |
No edit summary |
||
(15 intermediate revisions by the same user not shown) | |||
Line 2: | Line 2: | ||
== Introduction == | == Introduction == | ||
The article is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8<br></ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref><br>The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the | The article is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8<br></ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref><br>The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the [http://www.themoviedb.org/ TMDb database] rather than manually entering the movie name. The flow of this article is as follows : | ||
*The scope of discussion | *The scope of discussion | ||
Line 10: | Line 10: | ||
*Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber | *Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber | ||
*Explanation of the Background facility in Cucumber | *Explanation of the Background facility in Cucumber | ||
<b>Note : </b>All images used in this article have been taken from screen captures of Coursera video lectures available [https://class.coursera.org/saas-2012-003/class/index here]. All content is owned by original authors and there is no copyright infringement intended. References have been provided in the image descriptions wherever necessary | |||
==Scope== | ==Scope== | ||
The scope of this article is limited only to the scope covered in the video lecture. The lecture builds upon Behavior-Driven Development (BDD) basics discussed in the video lectures before it and sets the reader up for upcoming lectures concerning Test-Driven Development (TDD). Hence for the purpose of this article, it is assumed that the reader has already read the material and watched the video lectures before this one in the series. Hence the setup for Cucumber, Capybara and BDD basics are excluded from this article. The resources dealing with these can be found in the SaaS lectures 4.1 to 4.5 in the series. Similarly, the theory and implementation of TDD as well as further discussion on BDD is excluded from the scope of this article. More details on these can be found in lectures 4.7 to 5.11 of the SaaS lecture series .<ref>Software Engineering for SaaS, https://class.coursera.org/saas-2012-003/class/index </ref> | The scope of this article is limited only to the scope covered in the video lecture. The lecture builds upon [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-Driven Development (BDD)] basics discussed in the video lectures before it and sets the reader up for upcoming lectures concerning [http://en.wikipedia.org/wiki/Test-driven_development Test-Driven Development (TDD)]. Hence for the purpose of this article, it is assumed that the reader has already read the material and watched the video lectures before this one in the series. Hence the setup for Cucumber, Capybara and BDD basics are excluded from this article. The resources dealing with these can be found in the SaaS lectures 4.1 to 4.5 in the series. Similarly, the theory and implementation of TDD as well as further discussion on BDD is excluded from the scope of this article. More details on these can be found in lectures 4.7 to 5.11 of the SaaS lecture series .<ref>Software Engineering for SaaS, https://class.coursera.org/saas-2012-003/class/index </ref> | ||
==A Brief Recap== | ==A Brief Recap== | ||
Behavior-Driven Development (BDD) is a specialized development process which concentrates more on the behavioral aspects of the application as against the actual implementation of the application. <ref>Software Engineering for SaaS, https://class.coursera.org/saas-2012-003/class/index </ref> | Behavior-Driven Development (BDD) is a specialized development process which concentrates more on the behavioral aspects of the application as against the actual implementation of the application. <ref>Software Engineering for SaaS, https://class.coursera.org/saas-2012-003/class/index </ref> | ||
Storyboards are used to show how UI changes based on user actions. Even if it is tedious to draw sketches and storyboards, it helps build a ‘bigger picture’ understanding of the flow of the application for the non-technical stakeholders. | Storyboards are used to show how UI changes based on user actions. Even if it is tedious to draw sketches and storyboards, it helps build a ‘bigger picture’ understanding of the flow of the application for the non-technical stakeholders. | ||
Line 26: | Line 27: | ||
To do so, the ability to search TMDb from Rotten Potatoes home page needs to be incorporated in the webpage. Users can then search in TMDb if the movie is present in it and then its details can be imported into Rotten Potatoes. For integrating this feature into the application, first, a Lo-Fi UI and Storyboard is designed, which is described next. | To do so, the ability to search TMDb from Rotten Potatoes home page needs to be incorporated in the webpage. Users can then search in TMDb if the movie is present in it and then its details can be imported into Rotten Potatoes. For integrating this feature into the application, first, a Lo-Fi UI and Storyboard is designed, which is described next. | ||
==The | ===The Storyboard=== | ||
The Storyboard is to be interpreted as follows | The [http://en.wikipedia.org/wiki/Storyboard#Software Storyboard] is to be interpreted as follows | ||
When a person wants to add a new movie to the Movies list on Rotten Potatoes, he/she will enter the new movie name and click “Search”. The controller method should search the TMDb database for the given movie. If a match is found, i.e. the movie is present in the TMDb, then the “Match” page is displayed. If there is no match, otherwise “No Match” page is displayed. These two scenarios, are the Happy Path and Sad Path implementations respectively. | When a person wants to add a new movie to the Movies list on Rotten Potatoes, he/she will enter the new movie name and click “Search”. The controller method should search the TMDb database for the given movie. If a match is found, i.e. the movie is present in the TMDb, then the “Match” page is displayed. If there is no match, otherwise “No Match” page is displayed. These two scenarios, are the Happy Path and Sad Path implementations respectively. | ||
[[File:Storyboard.jpg|200 px|thumb|center|The Storyboard for the User Story. (Click Image to expand) ]] | [[File:Storyboard.jpg|200 px|thumb|center|The Storyboard for the User Story. (Click Image to expand) Source : https://class.coursera.org/saas-2012-003/class/index ]] | ||
==Happy Path, Sad Path and Bad path | ==Happy Path, Sad Path and Bad path== | ||
Many of us are aware of the test cases being categorized as Positive or Negative test cases. Similarly, for testing using Rails Cucumber, the tests cases are being categorized as Happy, Sad of Bad<ref>http://www.nishantverma.com/2010/03/test-case-paths-happy-sad-bad.html | |||
Many of us are aware of the test cases being categorized as Positive or Negative test cases. Similarly, for testing using Rails Cucumber, the tests cases are being categorized as Happy, Sad of Bad. A test case that results in a positive result is called a Happy Path. | </ref>. A test case that results in a positive result is called a Happy Path. E.g. On entering correct username and password on login page, the application logs the user in. | ||
A test case that yields no result is called a Sad Path. | A test case that yields no result is called a Sad Path. E.g. Entering invalid username or password on login page, which normally returns an ‘Incorrect username or password’ message | ||
A test case to handle an exceptional condition or situation, which the system should handle elegantly and show some message to the user is a Bad Path. E.g. Uploading image size exceeds a limited amount. User can then take corrective action | A test case to handle an exceptional condition or situation, which the system should handle elegantly and show some message to the user is a Bad Path. E.g. Uploading image size exceeds a limited amount. User can then take corrective action. | ||
==Elaboration of the User Story== | ===Elaboration of the User Story=== | ||
Let us consider the sad path scenario for the Search TMDb User Story Feature. | Let us consider the sad path scenario for the Search TMDb User Story Feature. | ||
<pre> | <pre> | ||
Line 58: | Line 59: | ||
The Test shown above has 6 steps (The logic and code for implementing this is provided in the TDD lectures in the Coursera series). | The Test shown above has 6 steps (The logic and code for implementing this is provided in the TDD lectures in the Coursera series). | ||
[[File:RottenPotatoes1.jpg|200 px|thumb|center|The Cucumber Test with Features and Scenarios ]] | [[File:RottenPotatoes1.jpg|200 px|thumb|center|The Cucumber Test with Features and Scenarios. (Click Image to expand) https://class.coursera.org/saas-2012-003/class/index ]] | ||
*First the test checks if the user is on the Home Page, viz. the Home page for the application exists. | *First the test checks if the user is on the Home Page, viz. the Home page for the application exists. | ||
Line 68: | Line 69: | ||
When we run the test, since there is already a home page, the first step of the scenario passes. | When we run the test, since there is already a home page, the first step of the scenario passes. | ||
[[File:RottenPotatoes2.jpg|200 px|thumb|center|Step for Home Page Passes. (Click Image to expand) ]] | [[File:RottenPotatoes2.jpg|200 px|thumb|center|Step for Home Page Passes. (Click Image to expand) https://class.coursera.org/saas-2012-003/class/index]] | ||
In the second step of the scenario, there is no link on the view for adding a new movie. Hence the second step fails and the following steps are skipped. | In the second step of the scenario, there is no link on the view for adding a new movie. Hence the second step fails and the following steps are skipped. | ||
[[File:RottenPotatoes3.jpg|200 px|thumb|center|However Step for the "search_tmdb" link fails and others after that are skipped ]] | [[File:RottenPotatoes3.jpg|200 px|thumb|center|However Step for the "search_tmdb" link fails and others after that are skipped. (Click Image to expand) https://class.coursera.org/saas-2012-003/class/index]] | ||
Now, we add the link for the “search_tmdb” action. For this, the [http://en.wikipedia.org/wiki/HAML HAML] for Search TMDb page should contain the following: | |||
<pre> | <pre> | ||
%h1 Search TMDb for a movie | %h1 Search TMDb for a movie | ||
Line 95: | Line 97: | ||
Now there is a page and a link in place for the test. On running the test using Cucumber again, the test fails again. This is because there is still no method defined in the controller (movies_controller.rb) for actually searching in TMDb. | Now there is a page and a link in place for the test. On running the test using Cucumber again, the test fails again. This is because there is still no method defined in the controller (movies_controller.rb) for actually searching in TMDb. | ||
[[File:RottenPotatoes4.jpg|200 px|thumb|center|The Link for search_tmdb is added to the view, but there is no method for search_tmdb in controller. Also there is no route. Hence these steps fail or are skipped ]] | [[File:RottenPotatoes4.jpg|200 px|thumb|center|The Link for search_tmdb is added to the view, but there is no method for search_tmdb in controller. Also there is no route. Hence these steps fail or are skipped. (Click Image to expand) https://class.coursera.org/saas-2012-003/class/index]] | ||
However the video tutorial in this discussion considers only the sad path scenario. To test this Sad path implementation, a dummy/fake method is defined in the movies_controller.rb which fails everytime, i.e. the search for the movie in TMDb never returns a match. | However the video tutorial in this discussion considers only the sad path scenario. To test this Sad path implementation, a dummy/fake method is defined in the movies_controller.rb which fails everytime, i.e. the search for the movie in TMDb never returns a match. | ||
Line 115: | Line 117: | ||
Now, on running the test again using Cucumber, every time the method is called, it returns a failure message (since it is hard-coded). This implies that the sad path implementation passed. | Now, on running the test again using Cucumber, every time the method is called, it returns a failure message (since it is hard-coded). This implies that the sad path implementation passed. | ||
[[File:RottenPotatoes5.jpg|200 px|thumb|center|Dummy method added to controller for 'search_tmdb' and then a route is also added. The dummy method fails everytime thereby satisfying the sad path scenario ]] | [[File:RottenPotatoes5.jpg|200 px|thumb|center|Dummy method added to controller for 'search_tmdb' and then a route is also added. The dummy method fails everytime thereby satisfying the sad path scenario. (Click Image to expand) https://class.coursera.org/saas-2012-003/class/index]] | ||
The actual code and logic for implementation of this action (search_tmdb) is discussed in later lectures which discuss the TDD (Test Driven Development) process | The actual code and logic for implementation of this action (search_tmdb) is discussed in later lectures which discuss the TDD (Test Driven Development) process | ||
Line 141: | Line 143: | ||
For implementation of this, instead of the hard coded Controller method, an actual controller method will have to written which searches TMDb and returns the details of the movie which will then be added to the Rotten Potatoes database. (However, this implementation is out of scope for our article. Further details of this can be found in the TDD lectures of this series.) | For implementation of this, instead of the hard coded Controller method, an actual controller method will have to written which searches TMDb and returns the details of the movie which will then be added to the Rotten Potatoes database. (However, this implementation is out of scope for our article. Further details of this can be found in the TDD lectures of this series.) | ||
Now, the Happy and the Sad paths have some code in common which violates the DRY principle. So, to make it DRY, Cucumber offers a solution called Background <ref>Background in Cucumber, https://github.com/cucumber/cucumber/wiki/Background</ref>. The steps which are common to both the paths are written in Background and those steps will run in the background before all the other scenarios. No matter what scenario one runs, the steps in the Background will run first, which will DRY out the code. This also helps in reducing the effort in case any steps leading up to the scenarios (setup) are to be modified. The tester will only have to change the code in one location. In this example there is only one happy path and sad path scenario i.e. only two scenarios. However, in real world examples, there would be a larger list of scenarios which could have the same ‘setup’. The advantages of the Background facility are more pronounced in this case. | Now, the Happy and the Sad paths have some code in common which violates the [http://en.wikipedia.org/wiki/Don't_repeat_yourself DRY principle]. So, to make it DRY, Cucumber offers a solution called Background <ref>Background in Cucumber, https://github.com/cucumber/cucumber/wiki/Background</ref>. The steps which are common to both the paths are written in Background and those steps will run in the background before all the other scenarios. No matter what scenario one runs, the steps in the Background will run first, which will DRY out the code. This also helps in reducing the effort in case any steps leading up to the scenarios (setup) are to be modified. The tester will only have to change the code in one location. In this example there is only one happy path and sad path scenario i.e. only two scenarios. However, in real world examples, there would be a larger list of scenarios which could have the same ‘setup’. The advantages of the Background facility are more pronounced in this case. | ||
[[File:BackgroundCucumber.jpg|200 px|thumb|center|The Cucumber Background ]] | [[File:BackgroundCucumber.jpg|200 px|thumb|center|The Cucumber Background. (Click Image to expand) https://class.coursera.org/saas-2012-003/class/index]] | ||
==Summary== | ==Summary== | ||
Line 153: | Line 155: | ||
<references/> | <references/> | ||
== Further Reading == | == Further Reading == | ||
[https://github.com/jnicklas/capybara Capybara] : Capybara introduction . | |||
[http://railscasts.com/episodes/275-how-i-test Railscast on testing in Capybara] : Railscast on testing in Capybara. | |||
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch1b_1w71_gs Capybara and Cucumber] : Capybara and Cucumber. | |||
[http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd The Truth about BDD] : The Truth about BDD. | |||
[http://benmabey.com/2008/05/10/slides-and-code-from-my-bddrspec-presentation.html BDD and RSpec] : BDD and RSpec. | |||
[http://www.allenwei.cn/cucumber-capybara-what-we-need-for-rails-integration-test/ Cucumber and Capybara for Rails] : Cucumber and Capybara for Rails. | |||
[http://rubysource.com/smelly-cucumbers/ Smelly Cucumbers] : Smelly Cucumbers. | |||
[http://cukes.info/ Cucumber] : Cucumber. | |||
[http://railscasts.com/episodes/155-beginning-with-cucumber Beginning with Cucumber] : Testing with Cucumber. |
Latest revision as of 17:51, 27 October 2012
SaaS 4.6 Enhancing Rotten Potatoes again
Introduction
The article is intended to be an accompaniment to the SaaS video lecture 4.6 titled “Enhancing Rotten Potatoes again” <ref name="video">Enhancing Rotten Potatoes again, http://www.youtube.com/watch?v=2l9uLw3y6J8
</ref>, part of the SaaS video lecture series for the Software Engineering for SaaS hosted on the Coursera learning network. <ref>Coursera, https://www.coursera.org/</ref>
The Rotten Potatoes webpage, designed in the previous lectures is enhanced for implementing a new feature to add a new movie by looking up the TMDb database rather than manually entering the movie name. The flow of this article is as follows :
- The scope of discussion
- Brief description of the storyboard used for the Lo-Fi UI design discussed in previous lectures in the video lecture series,
- Explanation of Sad path, Happy Path and Bad Path
- Description of the User Story developed in the video lecture
- Elaboration of the test scenarios written for the particular User story (including scenarios for happy and sad paths) in Cucumber
- Explanation of the Background facility in Cucumber
Note : All images used in this article have been taken from screen captures of Coursera video lectures available here. All content is owned by original authors and there is no copyright infringement intended. References have been provided in the image descriptions wherever necessary
Scope
The scope of this article is limited only to the scope covered in the video lecture. The lecture builds upon Behavior-Driven Development (BDD) basics discussed in the video lectures before it and sets the reader up for upcoming lectures concerning Test-Driven Development (TDD). Hence for the purpose of this article, it is assumed that the reader has already read the material and watched the video lectures before this one in the series. Hence the setup for Cucumber, Capybara and BDD basics are excluded from this article. The resources dealing with these can be found in the SaaS lectures 4.1 to 4.5 in the series. Similarly, the theory and implementation of TDD as well as further discussion on BDD is excluded from the scope of this article. More details on these can be found in lectures 4.7 to 5.11 of the SaaS lecture series .<ref>Software Engineering for SaaS, https://class.coursera.org/saas-2012-003/class/index </ref>
A Brief Recap
Behavior-Driven Development (BDD) is a specialized development process which concentrates more on the behavioral aspects of the application as against the actual implementation of the application. <ref>Software Engineering for SaaS, https://class.coursera.org/saas-2012-003/class/index </ref> Storyboards are used to show how UI changes based on user actions. Even if it is tedious to draw sketches and storyboards, it helps build a ‘bigger picture’ understanding of the flow of the application for the non-technical stakeholders.
Cucumber is one of the shining tools of Rails that is used for testing purposes. It acts as a halfway between the customer and the developer by converting user stories of 3x5 cards into tests. These tests act as Acceptance tests for ensuring the satisfaction of the customer. Also, the tests act as Integration tests that ensures the communication between modules is consistent and correct
The User Story
The aim of the User story described in the video is to add a new feature to the Rotten Potatoes web page, to add a new movie to the movies list on Rotten Potatoes page. But, for adding the movie to the list, it populates the data from TMDb rather than entering the information by hand. This is aimed at reducing repetitive work since the TMDb already has a good database of movies. To do so, the ability to search TMDb from Rotten Potatoes home page needs to be incorporated in the webpage. Users can then search in TMDb if the movie is present in it and then its details can be imported into Rotten Potatoes. For integrating this feature into the application, first, a Lo-Fi UI and Storyboard is designed, which is described next.
The Storyboard
The Storyboard is to be interpreted as follows When a person wants to add a new movie to the Movies list on Rotten Potatoes, he/she will enter the new movie name and click “Search”. The controller method should search the TMDb database for the given movie. If a match is found, i.e. the movie is present in the TMDb, then the “Match” page is displayed. If there is no match, otherwise “No Match” page is displayed. These two scenarios, are the Happy Path and Sad Path implementations respectively.
Happy Path, Sad Path and Bad path
Many of us are aware of the test cases being categorized as Positive or Negative test cases. Similarly, for testing using Rails Cucumber, the tests cases are being categorized as Happy, Sad of Bad<ref>http://www.nishantverma.com/2010/03/test-case-paths-happy-sad-bad.html </ref>. A test case that results in a positive result is called a Happy Path. E.g. On entering correct username and password on login page, the application logs the user in. A test case that yields no result is called a Sad Path. E.g. Entering invalid username or password on login page, which normally returns an ‘Incorrect username or password’ message A test case to handle an exceptional condition or situation, which the system should handle elegantly and show some message to the user is a Bad Path. E.g. Uploading image size exceeds a limited amount. User can then take corrective action.
Elaboration of the User Story
Let us consider the sad path scenario for the Search TMDb User Story Feature.
Feature: User can add movie by searching in The Movie Database(TMDb) User Story: As a movie fan So that I can add new movies without manual tedium I want to add movies by looking up their details in TMDb Scenario: Try to add non-existent movie (sad path) Given I am on the RottenPotatoes home page Then I should see "Search TMDb for a movie" When I fill in "Search Terms" with "Movie That Does Not Exist" And I press "Search TMDb" Then I should be on the RottenPotatoes home page And I should see "'Movie That Does Not Exist' was not found in TMDb."
The Test shown above has 6 steps (The logic and code for implementing this is provided in the TDD lectures in the Coursera series).
- First the test checks if the user is on the Home Page, viz. the Home page for the application exists.
- Next, it checks for presence of the link to “Search TMDb for movie”. The test essentially simulates what a normal user would do when testing the application manually.
- In the third step, the test populates the form for the Search, with a movie name that is not present in the TMDb (since this is a sad path implementation, the search should essentially fail.)
- Next, the test checks (simulates) if the link can be clicked.
- As a consequence of this, the user should navigate to the Rotten Potatoes home page.
- For a Sad path, the user is shown a message mentioning that there was no match, on the home page itself.
When we run the test, since there is already a home page, the first step of the scenario passes.
In the second step of the scenario, there is no link on the view for adding a new movie. Hence the second step fails and the following steps are skipped.
Now, we add the link for the “search_tmdb” action. For this, the HAML for Search TMDb page should contain the following:
%h1 Search TMDb for a movie = form_tag :action => 'search_tmdb' do %label{:for => 'search_terms'} Search Terms = text_field_tag 'search_terms' = submit_tag 'Search TMDb'
These are added into the end of app/views/movies/index.html.haml
The last two lines in the above code will be expanded into the HTML code:
<label for='search_terms'>Search Terms</label> <input id="search_terms" name="search_terms"type="text" />
Now there is a page and a link in place for the test. On running the test using Cucumber again, the test fails again. This is because there is still no method defined in the controller (movies_controller.rb) for actually searching in TMDb.
However the video tutorial in this discussion considers only the sad path scenario. To test this Sad path implementation, a dummy/fake method is defined in the movies_controller.rb which fails everytime, i.e. the search for the movie in TMDb never returns a match.
So, the following code for the fake controller method is added to the movies_controller.rb:
def search_tmdb # hardwire to simulate failure flash[:warning] = "'#{params[:search_terms]}' was not found in TMDb." redirect_to movies_path end
and since a new method has been added, we need to add a route to this controller method too. The following route is added to routes.db, just before or just after ‘resources :movies’
:
# Route that posts 'Search TMDb' form post '/movies/search_tmdb'
Now, on running the test again using Cucumber, every time the method is called, it returns a failure message (since it is hard-coded). This implies that the sad path implementation passed.
The actual code and logic for implementation of this action (search_tmdb) is discussed in later lectures which discuss the TDD (Test Driven Development) process
So far we have considered the Sad path scenario.
Let us consider the happy path scenario for the Search TMDb User Story Feature.
Feature: User can add movie by searching in The Movie Database(TMDb) User Story: As a movie fan So that I can add new movies without manual tedium I want to add movies by looking up their details in TMDb Scenario: Try to add existing movie (happy path) When I fill in "Search Terms" with "Inception" And I press "Search TMDb" Then I should be on the RottenPotatoes home page And I should see "Inception" And I should see "PG-13"
For implementation of this, instead of the hard coded Controller method, an actual controller method will have to written which searches TMDb and returns the details of the movie which will then be added to the Rotten Potatoes database. (However, this implementation is out of scope for our article. Further details of this can be found in the TDD lectures of this series.)
Now, the Happy and the Sad paths have some code in common which violates the DRY principle. So, to make it DRY, Cucumber offers a solution called Background <ref>Background in Cucumber, https://github.com/cucumber/cucumber/wiki/Background</ref>. The steps which are common to both the paths are written in Background and those steps will run in the background before all the other scenarios. No matter what scenario one runs, the steps in the Background will run first, which will DRY out the code. This also helps in reducing the effort in case any steps leading up to the scenarios (setup) are to be modified. The tester will only have to change the code in one location. In this example there is only one happy path and sad path scenario i.e. only two scenarios. However, in real world examples, there would be a larger list of scenarios which could have the same ‘setup’. The advantages of the Background facility are more pronounced in this case.
Summary
In summary, this article demonstrates the BDD/Cucumber test behaviour with the help of examples. It discusses the enhancement of Rotten Potatoes webpage for implementing a new feature, which is addition of a new movie by looking up the TMDb database rather than manually entering the movie name. This includes designing a Lo-Fi UI, writing scenarios and step definitions, even writing new methods for successfully executing the test cases using Cucumber. The article also introduces and explains the concept of Background in Cucumber, which helps in DRYing out the repeated code in scenarios of the same feature. The next chapter will discuss the TDD/RSpec behaviour and the approach to make all the scenarios pass.
Topical References
<references/>
Further Reading
Capybara : Capybara introduction .
Railscast on testing in Capybara : Railscast on testing in Capybara.
Capybara and Cucumber : Capybara and Cucumber.
The Truth about BDD : The Truth about BDD.
BDD and RSpec : BDD and RSpec.
Cucumber and Capybara for Rails : Cucumber and Capybara for Rails.
Smelly Cucumbers : Smelly Cucumbers.
Cucumber : Cucumber.
Beginning with Cucumber : Testing with Cucumber.