Your SlideShare is downloading. ×
Ruby on Rails Training - Module 2
Ruby on Rails Training - Module 2
Ruby on Rails Training - Module 2
Ruby on Rails Training - Module 2
Ruby on Rails Training - Module 2
Ruby on Rails Training - Module 2
Ruby on Rails Training - Module 2
Ruby on Rails Training - Module 2
Ruby on Rails Training - Module 2
Ruby on Rails Training - Module 2
Ruby on Rails Training - Module 2
Ruby on Rails Training - Module 2
Ruby on Rails Training - Module 2
Ruby on Rails Training - Module 2
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Ruby on Rails Training - Module 2

855

Published on

This module covers a bit about the development process I work with, RSpec, and a sample project called FastBooks.

This module covers a bit about the development process I work with, RSpec, and a sample project called FastBooks.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
855
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
6
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Transcript

    • 1. Ruby on RailsTraining Week 2Fast Books anExample ProjectUsing BehaviorDrivenDevelopmentby Mark MenardEnable Labs
    • 2. Fast Books A check book ledger program. You will learn about:  Behavior Driven Development  Story Carding  Cucumber  RSpec  Active Record Models  Validation  Associations  Action Controller  REST  Active View  ERB Templates 2
    • 3. Requirements The system should allow the management of multiple accounts The system should maintain an account ledger for every account in the system. Each account ledger should consist of ledger entries. Each ledger entry can be either a positive or negative value. Ledger entries can be associated with a payee and a category. 3
    • 4. Workflow Overview Story card use cases Create a new project Setup RSpec and Factory Girl Theme the project Define resource using: script/generate rspec_scaffold Create Cucumber scenarios specifying the stories in the application Write specification for model 4
    • 5. Story Carding Story cards are bits of narrative describing features of the system under development. They are called "cards" because in traditional extreme programming practice, they were written on paper index cards. The constraints of an index card were considered a plus -- the writing on the card is intended to be a marker for communication, not a comprehensive requirements document that fully describes the feature represented by the story. 5
    • 6. Story Carding Every interaction with the application should have a story card. Stories should be short and too the point. Stories are made up of four parts:  In order to < do some business value >  As a < actor > on < a context >  I want to < do something >  Acceptance criteria 6
    • 7. An Example Story CardIn order to track written checksAs a user on the account view pageI want to be able to add a check- view account page- click the add check button- fill in-- check number-- fill in payee Acceptance Criteria-- fill in amount-- fill in category-- fill in memo- click submit button- see new entry on account ledger 7
    • 8. Create Initial Story Cards Create account List accounts View account Edit account Write a check Make a deposit Add a payee Add a category View payee report View category report 8
    • 9. Behavior Driven Development Focus on what something should do. Encourages a literate style. Supports extraction of the specification in a readable format. Specs should be readable by domain experts. Specs should be executable. Should support testing code in isolation, integrated and full stack.  When the spec runs you’re done. 9
    • 10. Cucumber A high level behavior driven testing framework using plain language executable specifications. Feature: Contact Us As an anonymous user I want to be able to send a message So that I can receive support or get an answer to a question Scenario: Load Form Given I am on "home page" When I follow "Contact Us" Then I should see "Please use the following form" Scenario: Submitting form Given I am on the "contact us page" When I fill in "contact_handler[email]" with "me@example.com" And I fill in "contact_handler[subject]" with "Help" And I fill in "contact_handler[body]" with "Content" And I press "send" Then I should see "Thanks for your message." 10
    • 11. Create Initial Cucumber Scenarios View List Accounts Page Create Account View Account Edit Account 11
    • 12. RSpec RSpec provides a domain specific language with which you can express executable examples of the expected behavior of your code. RSpec includes support for mocking and stubbing. I use it as a replacement for unit and integration testing.  Models and controllers 12
    • 13. An RSpec Example You: Describe an account when it is first created. Customer: It should have a balance of $0.describe Account, "when first created" do it "should have a balance of $0" do ... endend When you run this example, RSpec can provide a report like this: Account when first created - should have a balance of $0 13
    • 14. The Check Register Data Model 14

    ×